You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <rd...@apache.org> on 2006/01/23 02:12:58 UTC
[logging] please check release candidate 1
i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
please check and test the release candidate and report any mistakes or
problems.
you'll probably notice that the jars are numbered 1.1 (not 1.1RC1 as is
more usual). i'd like to use a variation of the httpd/struts/tomcat
release approval process. i'll outline how this would work tomorrow.
BTW does anyone know a reliable way to convert unix->windoz file endings
for text file endings? (i know stephen prefers zip's to use windoz
format.)
- robert
Re: [logging] please check release candidate 1
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2006-01-23 at 01:12 +0000, robert burrell donkin wrote:
> i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> please check and test the release candidate and report any mistakes or
> problems.
>
> you'll probably notice that the jars are numbered 1.1 (not 1.1RC1 as is
> more usual). i'd like to use a variation of the httpd/struts/tomcat
> release approval process. i'll outline how this would work tomorrow.
>
> BTW does anyone know a reliable way to convert unix->windoz file endings
> for text file endings? (i know stephen prefers zip's to use windoz
> format.)
>
> - robert
Apart from the following, everything looks good:
* LogFactoryImpl present in adapters jar [fixed]
* javadoc for WeakHashtable refers to optional jar [fixed]
* javadoc for ServletContextCleaner doesn't mention WeakHashtable
[fixed]
* guide.xml had slightly wrong info about WeakHashtable
(*keys* are weak references, not *values*) [fixed]
Sorry I didn't pick these up earlier..
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-01-29 at 10:02 -0700, Phil Steitz wrote:
> On 1/24/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
<snip>
> > i'll probably just use svn, i think. svn export --native-eols=XXX should
> > do the line ending conversions automatically.
>
> This is better, IMHO than applying conversion in scripts, since it
> will make the distros independent of the OS platform used to do the
> build. It would be nice if maven did this by default when creating
> source distros.
unfortunately, i need a newer client and i've had not success in
building any client new enough. i really need to ditch mandrake and move
to gentoo...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Phil Steitz <ph...@gmail.com>.
On 1/24/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> On Tue, 2006-01-24 at 22:35 +0100, Dennis Lundberg wrote:
> > robert burrell donkin wrote:
> > > On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
> > >> On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
> > >>> On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> > >>>> Why is it necessary to use two different JVMs?
> > >>> need a 1.4 JVM to compile the java.util stuff but the rest of the code
> > >>> needs to run fine on earlier JVMs.
> > >>>
> > >>> javac settings will care of the differences in class formats but changes
> > >>> to the system libraries mean that you should compile against the 1.2
> > >>> java system libraries. this can be done either by using a 1.2 JSDK or by
> > >>> using a later JSDK and setting bootclasspath appropriately.
> > >>>
> > >>> if we were confident that our unit tests had 100% code coverage then
> > >>> compiling with a 1.4 JSDK would probably be safe enough. i'm not that
> > >>> confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
> > >>> more confident to use the system i know works.
> > >> Ok, sounds entirely reasonable. I agree there are corner cases where
> > >> target doesn't solve the problem (eg the new StringBuffer overloaded
> > >> methods in more recent JVMs).
> > >>
> > >> It might be nice to note this somewhere, eg as a comment in the
> > >> build.xml file or similar.
> > >
> > > the latest build.xml now supports dual compilation (1.2 and 1.4). the
> > > ant task should be run by a 1.2 JDK and a build.property set the a 1.4
> > > compiler. there's some documentation but i hope to return to this later
> > > (unless anyone else beats me to it).
> > >
> > > i'm now trying to think about whether to add a task to build the source
> > > distributions. one advantage is that it would automatically standardise
> > > the EOLs. one disadvantage is that it would require using exec to call
> > > svn directly. another is that it should really be loaded from a tag
> > > which would mean another build property.
> >
> > Robert, why would you need to use svn? If you are adding this to easy
> > the creating of RC:s and releases, then I would imagine that the release
> > manager has already checked out the correct tag from svn. If that is the
> > case then the source is already checked out as well, you just need to
> > package it.
>
> it's best to export a fresh copy from the tag. a couple of reasons:
>
> 1 this ensures that no svn meta-data is present
> 2 it ensure that no temporary files used when building the release are
> left in the source distribution
>
> i'll probably just use svn, i think. svn export --native-eols=XXX should
> do the line ending conversions automatically.
This is better, IMHO than applying conversion in scripts, since it
will make the distros independent of the OS platform used to do the
build. It would be nice if maven did this by default when creating
source distros.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-01-24 at 22:35 +0100, Dennis Lundberg wrote:
> robert burrell donkin wrote:
> > On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
> >> On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
> >>> On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> >>>> Why is it necessary to use two different JVMs?
> >>> need a 1.4 JVM to compile the java.util stuff but the rest of the code
> >>> needs to run fine on earlier JVMs.
> >>>
> >>> javac settings will care of the differences in class formats but changes
> >>> to the system libraries mean that you should compile against the 1.2
> >>> java system libraries. this can be done either by using a 1.2 JSDK or by
> >>> using a later JSDK and setting bootclasspath appropriately.
> >>>
> >>> if we were confident that our unit tests had 100% code coverage then
> >>> compiling with a 1.4 JSDK would probably be safe enough. i'm not that
> >>> confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
> >>> more confident to use the system i know works.
> >> Ok, sounds entirely reasonable. I agree there are corner cases where
> >> target doesn't solve the problem (eg the new StringBuffer overloaded
> >> methods in more recent JVMs).
> >>
> >> It might be nice to note this somewhere, eg as a comment in the
> >> build.xml file or similar.
> >
> > the latest build.xml now supports dual compilation (1.2 and 1.4). the
> > ant task should be run by a 1.2 JDK and a build.property set the a 1.4
> > compiler. there's some documentation but i hope to return to this later
> > (unless anyone else beats me to it).
> >
> > i'm now trying to think about whether to add a task to build the source
> > distributions. one advantage is that it would automatically standardise
> > the EOLs. one disadvantage is that it would require using exec to call
> > svn directly. another is that it should really be loaded from a tag
> > which would mean another build property.
>
> Robert, why would you need to use svn? If you are adding this to easy
> the creating of RC:s and releases, then I would imagine that the release
> manager has already checked out the correct tag from svn. If that is the
> case then the source is already checked out as well, you just need to
> package it.
it's best to export a fresh copy from the tag. a couple of reasons:
1 this ensures that no svn meta-data is present
2 it ensure that no temporary files used when building the release are
left in the source distribution
i'll probably just use svn, i think. svn export --native-eols=XXX should
do the line ending conversions automatically.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Dennis Lundberg <de...@apache.org>.
robert burrell donkin wrote:
> On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
>> On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
>>> On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
>>>> Why is it necessary to use two different JVMs?
>>> need a 1.4 JVM to compile the java.util stuff but the rest of the code
>>> needs to run fine on earlier JVMs.
>>>
>>> javac settings will care of the differences in class formats but changes
>>> to the system libraries mean that you should compile against the 1.2
>>> java system libraries. this can be done either by using a 1.2 JSDK or by
>>> using a later JSDK and setting bootclasspath appropriately.
>>>
>>> if we were confident that our unit tests had 100% code coverage then
>>> compiling with a 1.4 JSDK would probably be safe enough. i'm not that
>>> confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
>>> more confident to use the system i know works.
>> Ok, sounds entirely reasonable. I agree there are corner cases where
>> target doesn't solve the problem (eg the new StringBuffer overloaded
>> methods in more recent JVMs).
>>
>> It might be nice to note this somewhere, eg as a comment in the
>> build.xml file or similar.
>
> the latest build.xml now supports dual compilation (1.2 and 1.4). the
> ant task should be run by a 1.2 JDK and a build.property set the a 1.4
> compiler. there's some documentation but i hope to return to this later
> (unless anyone else beats me to it).
>
> i'm now trying to think about whether to add a task to build the source
> distributions. one advantage is that it would automatically standardise
> the EOLs. one disadvantage is that it would require using exec to call
> svn directly. another is that it should really be loaded from a tag
> which would mean another build property.
Robert, why would you need to use svn? If you are adding this to easy
the creating of RC:s and releases, then I would imagine that the release
manager has already checked out the correct tag from svn. If that is the
case then the source is already checked out as well, you just need to
package it.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
> On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
> > On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> > > Why is it necessary to use two different JVMs?
> >
> > need a 1.4 JVM to compile the java.util stuff but the rest of the code
> > needs to run fine on earlier JVMs.
> >
> > javac settings will care of the differences in class formats but changes
> > to the system libraries mean that you should compile against the 1.2
> > java system libraries. this can be done either by using a 1.2 JSDK or by
> > using a later JSDK and setting bootclasspath appropriately.
> >
> > if we were confident that our unit tests had 100% code coverage then
> > compiling with a 1.4 JSDK would probably be safe enough. i'm not that
> > confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
> > more confident to use the system i know works.
>
> Ok, sounds entirely reasonable. I agree there are corner cases where
> target doesn't solve the problem (eg the new StringBuffer overloaded
> methods in more recent JVMs).
>
> It might be nice to note this somewhere, eg as a comment in the
> build.xml file or similar.
the latest build.xml now supports dual compilation (1.2 and 1.4). the
ant task should be run by a 1.2 JDK and a build.property set the a 1.4
compiler. there's some documentation but i hope to return to this later
(unless anyone else beats me to it).
i'm now trying to think about whether to add a task to build the source
distributions. one advantage is that it would automatically standardise
the EOLs. one disadvantage is that it would require using exec to call
svn directly. another is that it should really be loaded from a tag
which would mean another build property.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
> On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> > Why is it necessary to use two different JVMs?
>
> need a 1.4 JVM to compile the java.util stuff but the rest of the code
> needs to run fine on earlier JVMs.
>
> javac settings will care of the differences in class formats but changes
> to the system libraries mean that you should compile against the 1.2
> java system libraries. this can be done either by using a 1.2 JSDK or by
> using a later JSDK and setting bootclasspath appropriately.
>
> if we were confident that our unit tests had 100% code coverage then
> compiling with a 1.4 JSDK would probably be safe enough. i'm not that
> confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
> more confident to use the system i know works.
Ok, sounds entirely reasonable. I agree there are corner cases where
target doesn't solve the problem (eg the new StringBuffer overloaded
methods in more recent JVMs).
It might be nice to note this somewhere, eg as a comment in the
build.xml file or similar.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> On Mon, 2006-01-23 at 22:07 +0000, robert burrell donkin wrote:
> > On Mon, 2006-01-23 at 10:05 +0100, Boris Unckel wrote:
<snip>
> > > Second 1.4.2_10 is the actual version, for a new release I would prefer the
> > > latest compiler (even if there a just minor or no changes). JCL releases
> > > have a long life cycle, and will be widely spread, so it makes sence to
> > > compile with the latest available version.
> >
> > sorry - my bad
> >
> > it got very late for me last night and i was too tired to check :(
> >
> > when i cut logging releases i do two compile runs (one with 1.2 and one
> > with a 1.4 JVMs) and then assemble the jars. used the wrong JVM to
> > assemble them.
>
> Why is it necessary to use two different JVMs?
need a 1.4 JVM to compile the java.util stuff but the rest of the code
needs to run fine on earlier JVMs.
javac settings will care of the differences in class formats but changes
to the system libraries mean that you should compile against the 1.2
java system libraries. this can be done either by using a 1.2 JSDK or by
using a later JSDK and setting bootclasspath appropriately.
if we were confident that our unit tests had 100% code coverage then
compiling with a 1.4 JSDK would probably be safe enough. i'm not that
confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
more confident to use the system i know works.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2006-01-23 at 22:07 +0000, robert burrell donkin wrote:
> On Mon, 2006-01-23 at 10:05 +0100, Boris Unckel wrote:
> > Hello,
> >
> >
> > robert burrell donkin <rd...@apache.org>
> > > i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> > > please check and test the release candidate and report any mistakes or
> > > problems.
> > >
> > Just to minor things:
> > - docs/api is empty, can be removed (docs/apidocs contains javadoc)
> >
> > - It is comiled with 1.4.2_04 (version from manifest.mf):
> > <!-- Version of java class files to generate. -->
> > <property name="target.version" value="1.1"/>
> >
> > <!-- Version of java source to accept -->
> > <property name="source.version" value="1.2"/>
> >
> > The release notes state it could be build for 1.1, but it is not tested.
> > Does the JDK1.4 compiler really produce 1.1 code? If not, I would set the
> > target.version to 1.2, to avoid errors which do not clearly lead to the
> > wrong class version.
Yes I believe the JDK1.4 compiler really does produce 1.1 code when told
to. Why wouldn't it?
We can't be sure that the resulting jar actually *does* run correctly on
java 1.1 because the unit tests require 1.2-or-later features. However
there's a good chance that the commons-logging.jar file *does* work on
jvm1.1, so it makes sense to compile for that target so that people who
care about that have at least an opportunity to try it.
> >
> > Second 1.4.2_10 is the actual version, for a new release I would prefer the
> > latest compiler (even if there a just minor or no changes). JCL releases
> > have a long life cycle, and will be widely spread, so it makes sence to
> > compile with the latest available version.
>
> sorry - my bad
>
> it got very late for me last night and i was too tired to check :(
>
> when i cut logging releases i do two compile runs (one with 1.2 and one
> with a 1.4 JVMs) and then assemble the jars. used the wrong JVM to
> assemble them.
Why is it necessary to use two different JVMs?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-01-23 at 10:05 +0100, Boris Unckel wrote:
> Hello,
>
>
> robert burrell donkin <rd...@apache.org>
> > i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> > please check and test the release candidate and report any mistakes or
> > problems.
> >
> Just to minor things:
> - docs/api is empty, can be removed (docs/apidocs contains javadoc)
>
> - It is comiled with 1.4.2_04 (version from manifest.mf):
> <!-- Version of java class files to generate. -->
> <property name="target.version" value="1.1"/>
>
> <!-- Version of java source to accept -->
> <property name="source.version" value="1.2"/>
>
> The release notes state it could be build for 1.1, but it is not tested.
> Does the JDK1.4 compiler really produce 1.1 code? If not, I would set the
> target.version to 1.2, to avoid errors which do not clearly lead to the
> wrong class version.
>
> Second 1.4.2_10 is the actual version, for a new release I would prefer the
> latest compiler (even if there a just minor or no changes). JCL releases
> have a long life cycle, and will be widely spread, so it makes sence to
> compile with the latest available version.
sorry - my bad
it got very late for me last night and i was too tired to check :(
when i cut logging releases i do two compile runs (one with 1.2 and one
with a 1.4 JVMs) and then assemble the jars. used the wrong JVM to
assemble them.
i need to write a proper ant script for this process. the feedback will
be useful when creating it.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Boris Unckel <bo...@gmx.net>.
Hello,
robert burrell donkin <rd...@apache.org>
> i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> please check and test the release candidate and report any mistakes or
> problems.
>
Just to minor things:
- docs/api is empty, can be removed (docs/apidocs contains javadoc)
- It is comiled with 1.4.2_04 (version from manifest.mf):
<!-- Version of java class files to generate. -->
<property name="target.version" value="1.1"/>
<!-- Version of java source to accept -->
<property name="source.version" value="1.2"/>
The release notes state it could be build for 1.1, but it is not tested.
Does the JDK1.4 compiler really produce 1.1 code? If not, I would set the
target.version to 1.2, to avoid errors which do not clearly lead to the
wrong class version.
Second 1.4.2_10 is the actual version, for a new release I would prefer the
latest compiler (even if there a just minor or no changes). JCL releases
have a long life cycle, and will be widely spread, so it makes sence to
compile with the latest available version.
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2006-01-23 at 01:12 +0000, robert burrell donkin wrote:
> i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> please check and test the release candidate and report any mistakes or
> problems.
>
> you'll probably notice that the jars are numbered 1.1 (not 1.1RC1 as is
> more usual). i'd like to use a variation of the httpd/struts/tomcat
> release approval process. i'll outline how this would work tomorrow.
>
> BTW does anyone know a reliable way to convert unix->windoz file endings
> for text file endings? (i know stephen prefers zip's to use windoz
> format.)
I've noticed the commons-logging-adapters.jar includes LogFactoryImpl.
I don't think this will actually do any harm, but I don't think it's
needed either. The LogFactory class always loads the default
o.a.c.l.impl.LogFactoryImpl class via its own classloader, never the
TCCL so it will never be used.
I'll commit a patch to remove this from the adapters jarfile.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-01-23 at 18:46 -0500, Rahul Akolkar wrote:
> On 1/23/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
<snip>
> > > I'm all for JCL 1.1, but IMO, the above approach should have been
> > > discussed before posting these files.
> >
> > it's just a few files posted to my home directory for checking. there
> > hasn't been a vote and no formal announcement. it's not a release, just
> > a bad release candidate.
> >
> <snip/>
>
> I understand, but consider this timeline:
>
> a) We put up binaries marked for a release that hasn't been voted on
> in personal webspace (but in the apache.org domain)
> b) We post on the dev list / in bugzilla entries asking folks to try these out
> c) Some do as suggested in (b)
> d) Changes are made to the code and/or packaging, and the release takes place
> e) Release is downloaded. Some in (c) update to correct binaries
> diligently, some forget
> f) We have differing copies of the same marked release out in the wild
>
> Marked as RC, things are different. FWIW, this was my concern.
yep but IMO the risks of this happening are pretty low (it'll be
replaced by another RC soon enough)
practical problems only start happening when the following happens:
g) someone uploads the jar to a repository
something similar has happened before to a commons library and it causes
trouble. so, the jar's need to be numbered.
> > but thanks for highlighting the issue: i've had a chance to sleep on
> > this and i think that they should have been versioned (even if that
> > makes my life a lot more difficult). RC2 will be.
> >
> <snap/>
>
> OK, and sorry for any trouble.
no trouble: you were right to highlight this issue
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/23/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
<snip/>
> >
> > Folks -
> >
> > Sincere apologies if this seems to be in the way of anyone doing the
> > real work. There are jars out there marked 1.1, and I'm not
> > comfortable with this. I'm aware of the httpd/struts/tomcat process,
> > but we need to collectively decide before any components start
> > deviating from (what I understand is) Commons policy.
>
> it's tradition rather than policy. the only policy we have is in the
> charter. the rest is social convention and tradition but that doesn't
> mean it's not important - in fact the opposite.
>
<snap/>
Yup, I merely exercised what I considered my social responsibility to ask :-)
> > I'm all for JCL 1.1, but IMO, the above approach should have been
> > discussed before posting these files.
>
> it's just a few files posted to my home directory for checking. there
> hasn't been a vote and no formal announcement. it's not a release, just
> a bad release candidate.
>
<snip/>
I understand, but consider this timeline:
a) We put up binaries marked for a release that hasn't been voted on
in personal webspace (but in the apache.org domain)
b) We post on the dev list / in bugzilla entries asking folks to try these out
c) Some do as suggested in (b)
d) Changes are made to the code and/or packaging, and the release takes place
e) Release is downloaded. Some in (c) update to correct binaries
diligently, some forget
f) We have differing copies of the same marked release out in the wild
Marked as RC, things are different. FWIW, this was my concern.
> but thanks for highlighting the issue: i've had a chance to sleep on
> this and i think that they should have been versioned (even if that
> makes my life a lot more difficult). RC2 will be.
>
<snap/>
OK, and sorry for any trouble.
-Rahul
> - robert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-01-22 at 20:40 -0500, Rahul Akolkar wrote:
> On 1/22/06, robert burrell donkin <rd...@apache.org> wrote:
> > i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> > please check and test the release candidate and report any mistakes or
> > problems.
> >
> > you'll probably notice that the jars are numbered 1.1 (not 1.1RC1 as is
> > more usual). i'd like to use a variation of the httpd/struts/tomcat
> > release approval process. i'll outline how this would work tomorrow.
> >
> <snip/>
>
> Folks -
>
> Sincere apologies if this seems to be in the way of anyone doing the
> real work. There are jars out there marked 1.1, and I'm not
> comfortable with this. I'm aware of the httpd/struts/tomcat process,
> but we need to collectively decide before any components start
> deviating from (what I understand is) Commons policy.
it's tradition rather than policy. the only policy we have is in the
charter. the rest is social convention and tradition but that doesn't
mean it's not important - in fact the opposite.
i have my reasons for wanting to discuss this in the VOTE thread rather
than trying to achieve a consensus before hand. one is that the release
needs checking and that takes a while. the release management plan can
be discussed concurrently.
> I'm all for JCL 1.1, but IMO, the above approach should have been
> discussed before posting these files.
it's just a few files posted to my home directory for checking. there
hasn't been a vote and no formal announcement. it's not a release, just
a bad release candidate.
but thanks for highlighting the issue: i've had a chance to sleep on
this and i think that they should have been versioned (even if that
makes my life a lot more difficult). RC2 will be.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/22/06, robert burrell donkin <rd...@apache.org> wrote:
> i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
> please check and test the release candidate and report any mistakes or
> problems.
>
> you'll probably notice that the jars are numbered 1.1 (not 1.1RC1 as is
> more usual). i'd like to use a variation of the httpd/struts/tomcat
> release approval process. i'll outline how this would work tomorrow.
>
<snip/>
Folks -
Sincere apologies if this seems to be in the way of anyone doing the
real work. There are jars out there marked 1.1, and I'm not
comfortable with this. I'm aware of the httpd/struts/tomcat process,
but we need to collectively decide before any components start
deviating from (what I understand is) Commons policy.
I'm all for JCL 1.1, but IMO, the above approach should have been
discussed before posting these files.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-01-23 at 19:57 +0000, sebb wrote:
> On 23/01/06, robert burrell donkin <rd...@apache.org> wrote:
>
> > BTW does anyone know a reliable way to convert unix->windoz file endings
> > for text file endings? (i know stephen prefers zip's to use windoz
> > format.)
>
> Can't you use the Ant fixcrlf task with eol="dos" or eol="crlf"?
cheers :)
(it was very late last night)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] please check release candidate 1
Posted by sebb <se...@gmail.com>.
On 23/01/06, robert burrell donkin <rd...@apache.org> wrote:
> BTW does anyone know a reliable way to convert unix->windoz file endings
> for text file endings? (i know stephen prefers zip's to use windoz
> format.)
Can't you use the Ant fixcrlf task with eol="dos" or eol="crlf"?
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org