You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Siegfried Goeschl <si...@it20one.at> on 2009/02/24 10:52:22 UTC
[VOTE] Release commons-exec-1.0.0 based on RC4
Hi folks,
the next release candidate ....
Tag:
https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
Site:
http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
Binaries:
http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
Let the fun begin ...
Siegfried Goeschl
PS: The test distribution is not part of the release but handy for
platform testing -
http://people.apache.org/~sgoeschl/download/commons-exec/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-exec-1.0.0 based on RC4
Posted by sebb <se...@gmail.com>.
On 24/02/2009, sebb <se...@gmail.com> wrote:
> On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> > Hi folks,
> >
> > the next release candidate ....
> >
> > Tag:
> >
> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
> >
> > Site:
> >
> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
> >
There does not appear to be a download link or page.
> > Binaries:
> >
> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>
>
> No such URL - did you mean:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/org/apache/commons/commons-exec/1.0.0/
>
Sigs and hashes all OK.
N&L files all present.
Source archive agrees with tag, except for the missing
findbugs-exclude-filter.xml.
It would be nice if the manifest files in the source and Javadoc jars
contained the following:
Implementation-Title: Commons Exec
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 1.0.0
Specification-Title: Commons Exec
Specification-Vendor: The Apache Software Foundation
Specification-Version: 1.0.0
[in particular, the version would be useful, as it is only in the jar name]
but that is not a blocker
The version string does not agree with most of the other Commons components.
I would expect the first release to be 1.0, not 1.0.0.
Overall, -0.5 because of the version string and missing download page.
>
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> >
> >
> > Let the fun begin ...
> >
> > Siegfried Goeschl
> >
> > PS: The test distribution is not part of the release but handy for
> > platform testing -
> > http://people.apache.org/~sgoeschl/download/commons-exec/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-exec-1.0.0 based on RC4
Posted by sebb <se...@gmail.com>.
On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi folks,
>
> the next release candidate ....
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>
> Site:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>
> Binaries:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
No such URL - did you mean:
http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/org/apache/commons/commons-exec/1.0.0/
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
>
> Let the fun begin ...
>
> Siegfried Goeschl
>
> PS: The test distribution is not part of the release but handy for
> platform testing -
> http://people.apache.org/~sgoeschl/download/commons-exec/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-exec-1.0.0 based on RC4
Posted by Luc Maisonobe <Lu...@free.fr>.
Siegfried Goeschl a écrit :
> Hi folks,
>
> the next release candidate ....
The findbugs-exclude-filter.xml file is not in the source archive, so
building everything from source fails. This can be fixed by adding it in
the src/assembly/src.xml file.
Otherwise, everything is fine to me.
+1 for the release.
Thanks for the good work
Luc
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>
> Site:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>
> Binaries:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
>
> Let the fun begin ...
>
> Siegfried Goeschl
>
> PS: The test distribution is not part of the release but handy for
> platform testing -
> http://people.apache.org/~sgoeschl/download/commons-exec/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Dennis,
thanks for your help - I thought I messed up something with my release
.... ;-)
Cheers,
Siegfried Goeschl
Dennis Lundberg wrote:
> Dennis Lundberg wrote:
>
>> Siegfried Goeschl wrote:
>>
>>> Hi folks,
>>>
>>> the current feedback requires a cancellation and a discussion
>>>
>>> 1) wrong download link in email - was a copy and paste error on my side
>>>
>>> 2) improved manifest in sources and javadoc jar - seems to be a parent
>>> pom issue and effects all M2 releases (checked commons-cli,
>>> commons-digester, commons-io, commons-jxpath)
>>>
>>> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
>>> http://commons.apache.org/releases/versioning.html the versioning is
>>> either correct or the docs are wrong
>>>
>>> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>>>
>>>
>>> So the open questions are ....
>>>
>>> ad 2) any quick ideas how to fix that? I will dig though the parent pom
>>> otherwise ...
>>>
>> This should be fixed in the parent POM. Documentation on how to do it
>> can be found here:
>> http://maven.apache.org/shared/maven-archiver/examples/manifest.html
>>
>> I'll fix it in a little bit...
>>
>
> The Javadoc jar part is now fixed in the parent POM. You can steal the
> configuration from there, if you don't want to wait for the parent to be
> released.
>
> The source jar can't be fixed right now, see
> http://jira.codehaus.org/browse/MSOURCES-36
> I'll see if I can't whip up a patch for that issue.
>
> IMO Commons Exec 1.0 doesn't have to wait for that issue to be solved,
> and a new version of Maven Source Plugin.
>
>
>>> ad 3) can we agree an ONE schema which is properly documented - I'm fed
>>> up with some undocumented guidelines resulting in not enough +1 to get
>>> commons-exec out of the door, e.g. groupId or versioning. I propose we
>>> find a common understanding which I put into the commons wiki.
>>>
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>> Siegfried Goeschl wrote:
>>>
>>>> Hi folks,
>>>>
>>>> the next release candidate ....
>>>>
>>>> Tag:
>>>>
>>>> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>>>>
>>>> Site:
>>>>
>>>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>>>>
>>>> Binaries:
>>>>
>>>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>>>>
>>>> [ ] +1 release it
>>>> [ ] +0 go ahead I don't care
>>>> [ ] -1 no, do not release it because
>>>>
>>>>
>>>> Let the fun begin ...
>>>>
>>>> Siegfried Goeschl
>>>>
>>>> PS: The test distribution is not part of the release but handy for
>>>> platform testing -
>>>> http://people.apache.org/~sgoeschl/download/commons-exec/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Dennis Lundberg <de...@apache.org>.
Dennis Lundberg wrote:
> Siegfried Goeschl wrote:
>> Hi folks,
>>
>> the current feedback requires a cancellation and a discussion
>>
>> 1) wrong download link in email - was a copy and paste error on my side
>>
>> 2) improved manifest in sources and javadoc jar - seems to be a parent
>> pom issue and effects all M2 releases (checked commons-cli,
>> commons-digester, commons-io, commons-jxpath)
>>
>> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
>> http://commons.apache.org/releases/versioning.html the versioning is
>> either correct or the docs are wrong
>>
>> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>>
>>
>> So the open questions are ....
>>
>> ad 2) any quick ideas how to fix that? I will dig though the parent pom
>> otherwise ...
>
> This should be fixed in the parent POM. Documentation on how to do it
> can be found here:
> http://maven.apache.org/shared/maven-archiver/examples/manifest.html
>
> I'll fix it in a little bit...
The Javadoc jar part is now fixed in the parent POM. You can steal the
configuration from there, if you don't want to wait for the parent to be
released.
The source jar can't be fixed right now, see
http://jira.codehaus.org/browse/MSOURCES-36
I'll see if I can't whip up a patch for that issue.
IMO Commons Exec 1.0 doesn't have to wait for that issue to be solved,
and a new version of Maven Source Plugin.
>> ad 3) can we agree an ONE schema which is properly documented - I'm fed
>> up with some undocumented guidelines resulting in not enough +1 to get
>> commons-exec out of the door, e.g. groupId or versioning. I propose we
>> find a common understanding which I put into the commons wiki.
>>
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>> Siegfried Goeschl wrote:
>>> Hi folks,
>>>
>>> the next release candidate ....
>>>
>>> Tag:
>>>
>>> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>>>
>>> Site:
>>>
>>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>>>
>>> Binaries:
>>>
>>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because
>>>
>>>
>>> Let the fun begin ...
>>>
>>> Siegfried Goeschl
>>>
>>> PS: The test distribution is not part of the release but handy for
>>> platform testing -
>>> http://people.apache.org/~sgoeschl/download/commons-exec/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Dennis Lundberg <de...@apache.org>.
Siegfried Goeschl wrote:
> Hi folks,
>
> the current feedback requires a cancellation and a discussion
>
> 1) wrong download link in email - was a copy and paste error on my side
>
> 2) improved manifest in sources and javadoc jar - seems to be a parent
> pom issue and effects all M2 releases (checked commons-cli,
> commons-digester, commons-io, commons-jxpath)
>
> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
> http://commons.apache.org/releases/versioning.html the versioning is
> either correct or the docs are wrong
>
> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>
>
> So the open questions are ....
>
> ad 2) any quick ideas how to fix that? I will dig though the parent pom
> otherwise ...
This should be fixed in the parent POM. Documentation on how to do it
can be found here:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
I'll fix it in a little bit...
> ad 3) can we agree an ONE schema which is properly documented - I'm fed
> up with some undocumented guidelines resulting in not enough +1 to get
> commons-exec out of the door, e.g. groupId or versioning. I propose we
> find a common understanding which I put into the commons wiki.
>
>
> Cheers,
>
> Siegfried Goeschl
>
> Siegfried Goeschl wrote:
>> Hi folks,
>>
>> the next release candidate ....
>>
>> Tag:
>>
>> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>>
>> Binaries:
>>
>> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>>
>> Let the fun begin ...
>>
>> Siegfried Goeschl
>>
>> PS: The test distribution is not part of the release but handy for
>> platform testing -
>> http://people.apache.org/~sgoeschl/download/commons-exec/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by sebb <se...@gmail.com>.
On 25/02/2009, Mark Thomas <ma...@apache.org> wrote:
> sebb wrote:
> > 1.0.1 - for a point release
> > 1.1 for a minor release
> >
> > But the first release would be 1.0.
>
>
> If you follow your point to it's logical conclusion, it should be '1'
> rather than '1.0' or '1.0.0'
Except that the minor number is not optional.
> As per http://commons.apache.org/releases/versioning.html, either 1.0 or
> 1.0.0 is acceptable.
Yes, but almost all other Commons components use 1.0.
Probably other ASF projects too.
>
> Mark
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Mark Thomas <ma...@apache.org>.
sebb wrote:
> 1.0.1 - for a point release
> 1.1 for a minor release
>
> But the first release would be 1.0.
If you follow your point to it's logical conclusion, it should be '1'
rather than '1.0' or '1.0.0'
As per http://commons.apache.org/releases/versioning.html, either 1.0 or
1.0.0 is acceptable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by sebb <se...@gmail.com>.
On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi folks,
>
> I think you lost me ....
>
> +) assuming that commons-exec-1.0.0 is out there what would be the
> version number for a bugfix only release - would it be 1.1?!
1.0.1 - for a point release
1.1 for a minor release
But the first release would be 1.0.
> +) assuming that the version numbering schema consists of three parts -
> why should I start with 1.0 and not with 1.0.0?!
Because the trailing .0 is optional.
> Within the Apache community there is strong consensus regarding a three
> part version numbering schema when looking at the official documentation
>
> +) http://apr.apache.org/versioning.html
> +) http://commons.apache.org/releases/versioning.html
This says that the .0 point release is optional.
>
> Within Apache Commons a lot of projects are using a three part version
> number
But mainly where there is a two-part release preceeding it:
> +) commons-dbcp
The archive site has:
1.0, 1.1, 1.2, 1.2.1, 1.2.2
> +) commons-collections
1.0, 2.0, 2.1, 2.1.1, 3.0, 3.1, 3.2, 3.2.1
> +) commons-daemon
> +) commons-fileupload
> +) commons-httpclient
> +) commons-io
> +) commons-logging
> +) commons-net
> So me reasoning is
>
> +) having a three part version number is a sensible approach
Agreed.
> +) consequently the very first version is 1.0.0 to be consistent
Disagree; it's not necessary to use 1.0.0; 1.0 will do just as well.
> +) it is up to the project lead to decide if an update of the minor or
> point release number is required
Well, there are rules for what constitutes a point release, but if one
is needed, then by all means create 1.0.1 or 1.0.2 etc.
> +) and yes, I'm rocking the boat .... :-)
> Cheers,
>
>
> Siegfried Goeschl
>
>
> Luc Maisonobe wrote:
> > sebb a écrit :
> >
> >> On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> >>
> >>> Hi Sebastian,
> >>>
> >>> IMO avoiding point release is a mistake because you loose a strong
> >>> statement regarding backward compatibility
> >>>
> >> But there is nothing here to be compatible with ...
> >>
> >>
> >>> +) commons-exec-1.0.0 is out but contains a stupid bug
> >>>
> >> That should be 1.0
> >>
> >
> > I second that.
> >
> >
> >>> +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures
> >>>
> >> Agreed.
> >>
> >>
> >>> +) commons-exec-1.1.0 contains the bugfixes but exposes more feature
> >>> (and might accidently break a client)
> >>>
> >> That would be 1.1
> >>
> >
> > I second that too.
> >
> > Very often, product versioning seems to be afraid of incrementing a
> > number. This was clearly visible in Sun products (Solaris and Java) when
> > they finally drop the first digits when they realize they don't mean
> > anything anymore. The worst case is Perl, I don't even remember the
> > number intermediate non-sense 0 digits that were put between the leading
> > '5' and the final release digits, as if 5.1, 5.2 was too frightening.
> >
> > So a simple 2 digits scheme is far enough for many cases.
> >
> > Luc
> >
> >
> >>> In short - a point release guarantees no deployment problems which is
> >>> not the case for a new minor release.
> >>>
> >> Exactly.
> >>
> >>
> >>> Cheers,
> >>>
> >>>
> >>> Siegfried Goeschl
> >>>
> >>>
> >>> sebb wrote:
> >>> > On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> >>> >
> >>> >> Hi folks,
> >>> >>
> >>> >> the current feedback requires a cancellation and a discussion
> >>> >>
> >>> >> 1) wrong download link in email - was a copy and paste error on my side
> >>> >>
> >>> >> 2) improved manifest in sources and javadoc jar - seems to be a parent
> >>> >> pom issue and effects all M2 releases (checked commons-cli,
> >>> >> commons-digester, commons-io, commons-jxpath)
> >>> >>
> >>> >> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
> >>> >> http://commons.apache.org/releases/versioning.html the versioning is
> >>> >> either correct or the docs are wrong
> >>> >>
> >>> >
> >>> > I had not seen that. However, as far as I can tell, hardly any of the
> >>> > other commons components uses the final [.0]. Only NET seems to have
> >>> > started with 1.0.0.
> >>> >
> >>> > As I understand it, point releases are used for minor updates to an
> >>> > *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
> >>> >
> >>> > So although it appears to be allowed by the document, I think it would
> >>> > be better to reserve the point marker for point releases.
> >>> >
> >>> >
> >>> >> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
> >>> >>
> >>> >>
> >>> >> So the open questions are ....
> >>> >>
> >>> >> ad 2) any quick ideas how to fix that? I will dig though the parent pom
> >>> >> otherwise ...
> >>> >>
> >>> >> ad 3) can we agree an ONE schema which is properly documented - I'm fed
> >>> >> up with some undocumented guidelines resulting in not enough +1 to get
> >>> >> commons-exec out of the door, e.g. groupId or versioning. I propose we
> >>> >> find a common understanding which I put into the commons wiki.
> >>> >>
> >>> >
> >>> > If there are any clarifications to be made, the versioning guidelines
> >>> > document needs to be updated, not the wiki.
> >>> >
> >>> >
> >>> >> Cheers,
> >>> >>
> >>> >> Siegfried Goeschl
> >>> >>
> >>> >> Siegfried Goeschl wrote:
> >>> >> > Hi folks,
> >>> >> >
> >>> >> > the next release candidate ....
> >>> >> >
> >>> >> > Tag:
> >>> >> >
> >>> >> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
> >>> >> >
> >>> >> > Site:
> >>> >> >
> >>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
> >>> >> >
> >>> >> > Binaries:
> >>> >> >
> >>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
> >>> >> >
> >>> >> > [ ] +1 release it
> >>> >> > [ ] +0 go ahead I don't care
> >>> >> > [ ] -1 no, do not release it because
> >>> >> >
> >>> >> >
> >>> >> > Let the fun begin ...
> >>> >> >
> >>> >> > Siegfried Goeschl
> >>> >> >
> >>> >> > PS: The test distribution is not part of the release but handy for
> >>> >> > platform testing -
> >>> >> > http://people.apache.org/~sgoeschl/download/commons-exec/
> >>> >> >
> >>> >> > ---------------------------------------------------------------------
> >>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> > For additional commands, e-mail: dev-help@commons.apache.org
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi folks,
I think you lost me ....
+) assuming that commons-exec-1.0.0 is out there what would be the
version number for a bugfix only release - would it be 1.1?!
+) assuming that the version numbering schema consists of three parts -
why should I start with 1.0 and not with 1.0.0?!
Within the Apache community there is strong consensus regarding a three
part version numbering schema when looking at the official documentation
+) http://apr.apache.org/versioning.html
+) http://commons.apache.org/releases/versioning.html
Within Apache Commons a lot of projects are using a three part version
number
+) commons-dbcp
+) commons-collections
+) commons-daemon
+) commons-fileupload
+) commons-httpclient
+) commons-io
+) commons-logging
+) commons-net
So me reasoning is
+) having a three part version number is a sensible approach
+) consequently the very first version is 1.0.0 to be consistent
+) it is up to the project lead to decide if an update of the minor or
point release number is required
+) and yes, I'm rocking the boat .... :-)
Cheers,
Siegfried Goeschl
Luc Maisonobe wrote:
> sebb a écrit :
>
>> On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
>>
>>> Hi Sebastian,
>>>
>>> IMO avoiding point release is a mistake because you loose a strong
>>> statement regarding backward compatibility
>>>
>> But there is nothing here to be compatible with ...
>>
>>
>>> +) commons-exec-1.0.0 is out but contains a stupid bug
>>>
>> That should be 1.0
>>
>
> I second that.
>
>
>>> +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures
>>>
>> Agreed.
>>
>>
>>> +) commons-exec-1.1.0 contains the bugfixes but exposes more feature
>>> (and might accidently break a client)
>>>
>> That would be 1.1
>>
>
> I second that too.
>
> Very often, product versioning seems to be afraid of incrementing a
> number. This was clearly visible in Sun products (Solaris and Java) when
> they finally drop the first digits when they realize they don't mean
> anything anymore. The worst case is Perl, I don't even remember the
> number intermediate non-sense 0 digits that were put between the leading
> '5' and the final release digits, as if 5.1, 5.2 was too frightening.
>
> So a simple 2 digits scheme is far enough for many cases.
>
> Luc
>
>
>>> In short - a point release guarantees no deployment problems which is
>>> not the case for a new minor release.
>>>
>> Exactly.
>>
>>
>>> Cheers,
>>>
>>>
>>> Siegfried Goeschl
>>>
>>>
>>> sebb wrote:
>>> > On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
>>> >
>>> >> Hi folks,
>>> >>
>>> >> the current feedback requires a cancellation and a discussion
>>> >>
>>> >> 1) wrong download link in email - was a copy and paste error on my side
>>> >>
>>> >> 2) improved manifest in sources and javadoc jar - seems to be a parent
>>> >> pom issue and effects all M2 releases (checked commons-cli,
>>> >> commons-digester, commons-io, commons-jxpath)
>>> >>
>>> >> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
>>> >> http://commons.apache.org/releases/versioning.html the versioning is
>>> >> either correct or the docs are wrong
>>> >>
>>> >
>>> > I had not seen that. However, as far as I can tell, hardly any of the
>>> > other commons components uses the final [.0]. Only NET seems to have
>>> > started with 1.0.0.
>>> >
>>> > As I understand it, point releases are used for minor updates to an
>>> > *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
>>> >
>>> > So although it appears to be allowed by the document, I think it would
>>> > be better to reserve the point marker for point releases.
>>> >
>>> >
>>> >> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>>> >>
>>> >>
>>> >> So the open questions are ....
>>> >>
>>> >> ad 2) any quick ideas how to fix that? I will dig though the parent pom
>>> >> otherwise ...
>>> >>
>>> >> ad 3) can we agree an ONE schema which is properly documented - I'm fed
>>> >> up with some undocumented guidelines resulting in not enough +1 to get
>>> >> commons-exec out of the door, e.g. groupId or versioning. I propose we
>>> >> find a common understanding which I put into the commons wiki.
>>> >>
>>> >
>>> > If there are any clarifications to be made, the versioning guidelines
>>> > document needs to be updated, not the wiki.
>>> >
>>> >
>>> >> Cheers,
>>> >>
>>> >> Siegfried Goeschl
>>> >>
>>> >> Siegfried Goeschl wrote:
>>> >> > Hi folks,
>>> >> >
>>> >> > the next release candidate ....
>>> >> >
>>> >> > Tag:
>>> >> >
>>> >> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>>> >> >
>>> >> > Site:
>>> >> >
>>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>>> >> >
>>> >> > Binaries:
>>> >> >
>>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>>> >> >
>>> >> > [ ] +1 release it
>>> >> > [ ] +0 go ahead I don't care
>>> >> > [ ] -1 no, do not release it because
>>> >> >
>>> >> >
>>> >> > Let the fun begin ...
>>> >> >
>>> >> > Siegfried Goeschl
>>> >> >
>>> >> > PS: The test distribution is not part of the release but handy for
>>> >> > platform testing -
>>> >> > http://people.apache.org/~sgoeschl/download/commons-exec/
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >
>>> >
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Luc Maisonobe <Lu...@free.fr>.
sebb a écrit :
> On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
>> Hi Sebastian,
>>
>> IMO avoiding point release is a mistake because you loose a strong
>> statement regarding backward compatibility
>
> But there is nothing here to be compatible with ...
>
>> +) commons-exec-1.0.0 is out but contains a stupid bug
>
> That should be 1.0
I second that.
>
>> +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures
>
> Agreed.
>
>> +) commons-exec-1.1.0 contains the bugfixes but exposes more feature
>> (and might accidently break a client)
>
> That would be 1.1
I second that too.
Very often, product versioning seems to be afraid of incrementing a
number. This was clearly visible in Sun products (Solaris and Java) when
they finally drop the first digits when they realize they don't mean
anything anymore. The worst case is Perl, I don't even remember the
number intermediate non-sense 0 digits that were put between the leading
'5' and the final release digits, as if 5.1, 5.2 was too frightening.
So a simple 2 digits scheme is far enough for many cases.
Luc
>
>> In short - a point release guarantees no deployment problems which is
>> not the case for a new minor release.
>
> Exactly.
>
>> Cheers,
>>
>>
>> Siegfried Goeschl
>>
>>
>> sebb wrote:
>> > On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
>> >
>> >> Hi folks,
>> >>
>> >> the current feedback requires a cancellation and a discussion
>> >>
>> >> 1) wrong download link in email - was a copy and paste error on my side
>> >>
>> >> 2) improved manifest in sources and javadoc jar - seems to be a parent
>> >> pom issue and effects all M2 releases (checked commons-cli,
>> >> commons-digester, commons-io, commons-jxpath)
>> >>
>> >> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
>> >> http://commons.apache.org/releases/versioning.html the versioning is
>> >> either correct or the docs are wrong
>> >>
>> >
>> > I had not seen that. However, as far as I can tell, hardly any of the
>> > other commons components uses the final [.0]. Only NET seems to have
>> > started with 1.0.0.
>> >
>> > As I understand it, point releases are used for minor updates to an
>> > *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
>> >
>> > So although it appears to be allowed by the document, I think it would
>> > be better to reserve the point marker for point releases.
>> >
>> >
>> >> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>> >>
>> >>
>> >> So the open questions are ....
>> >>
>> >> ad 2) any quick ideas how to fix that? I will dig though the parent pom
>> >> otherwise ...
>> >>
>> >> ad 3) can we agree an ONE schema which is properly documented - I'm fed
>> >> up with some undocumented guidelines resulting in not enough +1 to get
>> >> commons-exec out of the door, e.g. groupId or versioning. I propose we
>> >> find a common understanding which I put into the commons wiki.
>> >>
>> >
>> > If there are any clarifications to be made, the versioning guidelines
>> > document needs to be updated, not the wiki.
>> >
>> >
>> >> Cheers,
>> >>
>> >> Siegfried Goeschl
>> >>
>> >> Siegfried Goeschl wrote:
>> >> > Hi folks,
>> >> >
>> >> > the next release candidate ....
>> >> >
>> >> > Tag:
>> >> >
>> >> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>> >> >
>> >> > Site:
>> >> >
>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>> >> >
>> >> > Binaries:
>> >> >
>> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>> >> >
>> >> > [ ] +1 release it
>> >> > [ ] +0 go ahead I don't care
>> >> > [ ] -1 no, do not release it because
>> >> >
>> >> >
>> >> > Let the fun begin ...
>> >> >
>> >> > Siegfried Goeschl
>> >> >
>> >> > PS: The test distribution is not part of the release but handy for
>> >> > platform testing -
>> >> > http://people.apache.org/~sgoeschl/download/commons-exec/
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by sebb <se...@gmail.com>.
On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi Sebastian,
>
> IMO avoiding point release is a mistake because you loose a strong
> statement regarding backward compatibility
But there is nothing here to be compatible with ...
> +) commons-exec-1.0.0 is out but contains a stupid bug
That should be 1.0
> +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures
Agreed.
> +) commons-exec-1.1.0 contains the bugfixes but exposes more feature
> (and might accidently break a client)
That would be 1.1
> In short - a point release guarantees no deployment problems which is
> not the case for a new minor release.
Exactly.
> Cheers,
>
>
> Siegfried Goeschl
>
>
> sebb wrote:
> > On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> >
> >> Hi folks,
> >>
> >> the current feedback requires a cancellation and a discussion
> >>
> >> 1) wrong download link in email - was a copy and paste error on my side
> >>
> >> 2) improved manifest in sources and javadoc jar - seems to be a parent
> >> pom issue and effects all M2 releases (checked commons-cli,
> >> commons-digester, commons-io, commons-jxpath)
> >>
> >> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
> >> http://commons.apache.org/releases/versioning.html the versioning is
> >> either correct or the docs are wrong
> >>
> >
> > I had not seen that. However, as far as I can tell, hardly any of the
> > other commons components uses the final [.0]. Only NET seems to have
> > started with 1.0.0.
> >
> > As I understand it, point releases are used for minor updates to an
> > *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
> >
> > So although it appears to be allowed by the document, I think it would
> > be better to reserve the point marker for point releases.
> >
> >
> >> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
> >>
> >>
> >> So the open questions are ....
> >>
> >> ad 2) any quick ideas how to fix that? I will dig though the parent pom
> >> otherwise ...
> >>
> >> ad 3) can we agree an ONE schema which is properly documented - I'm fed
> >> up with some undocumented guidelines resulting in not enough +1 to get
> >> commons-exec out of the door, e.g. groupId or versioning. I propose we
> >> find a common understanding which I put into the commons wiki.
> >>
> >
> > If there are any clarifications to be made, the versioning guidelines
> > document needs to be updated, not the wiki.
> >
> >
> >> Cheers,
> >>
> >> Siegfried Goeschl
> >>
> >> Siegfried Goeschl wrote:
> >> > Hi folks,
> >> >
> >> > the next release candidate ....
> >> >
> >> > Tag:
> >> >
> >> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
> >> >
> >> > Site:
> >> >
> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
> >> >
> >> > Binaries:
> >> >
> >> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
> >> >
> >> > [ ] +1 release it
> >> > [ ] +0 go ahead I don't care
> >> > [ ] -1 no, do not release it because
> >> >
> >> >
> >> > Let the fun begin ...
> >> >
> >> > Siegfried Goeschl
> >> >
> >> > PS: The test distribution is not part of the release but handy for
> >> > platform testing -
> >> > http://people.apache.org/~sgoeschl/download/commons-exec/
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Sebastian,
IMO avoiding point release is a mistake because you loose a strong
statement regarding backward compatibility
+) commons-exec-1.0.0 is out but contains a stupid bug
+) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures
+) commons-exec-1.1.0 contains the bugfixes but exposes more feature
(and might accidently break a client)
In short - a point release guarantees no deployment problems which is
not the case for a new minor release.
Cheers,
Siegfried Goeschl
sebb wrote:
> On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
>
>> Hi folks,
>>
>> the current feedback requires a cancellation and a discussion
>>
>> 1) wrong download link in email - was a copy and paste error on my side
>>
>> 2) improved manifest in sources and javadoc jar - seems to be a parent
>> pom issue and effects all M2 releases (checked commons-cli,
>> commons-digester, commons-io, commons-jxpath)
>>
>> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
>> http://commons.apache.org/releases/versioning.html the versioning is
>> either correct or the docs are wrong
>>
>
> I had not seen that. However, as far as I can tell, hardly any of the
> other commons components uses the final [.0]. Only NET seems to have
> started with 1.0.0.
>
> As I understand it, point releases are used for minor updates to an
> *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
>
> So although it appears to be allowed by the document, I think it would
> be better to reserve the point marker for point releases.
>
>
>> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>>
>>
>> So the open questions are ....
>>
>> ad 2) any quick ideas how to fix that? I will dig though the parent pom
>> otherwise ...
>>
>> ad 3) can we agree an ONE schema which is properly documented - I'm fed
>> up with some undocumented guidelines resulting in not enough +1 to get
>> commons-exec out of the door, e.g. groupId or versioning. I propose we
>> find a common understanding which I put into the commons wiki.
>>
>
> If there are any clarifications to be made, the versioning guidelines
> document needs to be updated, not the wiki.
>
>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>> Siegfried Goeschl wrote:
>> > Hi folks,
>> >
>> > the next release candidate ....
>> >
>> > Tag:
>> >
>> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>> >
>> > Site:
>> >
>> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>> >
>> > Binaries:
>> >
>> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>> >
>> > [ ] +1 release it
>> > [ ] +0 go ahead I don't care
>> > [ ] -1 no, do not release it because
>> >
>> >
>> > Let the fun begin ...
>> >
>> > Siegfried Goeschl
>> >
>> > PS: The test distribution is not part of the release but handy for
>> > platform testing -
>> > http://people.apache.org/~sgoeschl/download/commons-exec/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by sebb <se...@gmail.com>.
On 24/02/2009, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi folks,
>
> the current feedback requires a cancellation and a discussion
>
> 1) wrong download link in email - was a copy and paste error on my side
>
> 2) improved manifest in sources and javadoc jar - seems to be a parent
> pom issue and effects all M2 releases (checked commons-cli,
> commons-digester, commons-io, commons-jxpath)
>
> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
> http://commons.apache.org/releases/versioning.html the versioning is
> either correct or the docs are wrong
I had not seen that. However, as far as I can tell, hardly any of the
other commons components uses the final [.0]. Only NET seems to have
started with 1.0.0.
As I understand it, point releases are used for minor updates to an
*existing* release. E.g. Commons Lang released 1.0 and then 1.0.1.
So although it appears to be allowed by the document, I think it would
be better to reserve the point marker for point releases.
> 4) missing findbugs-exclude-filter.xml - well, that's a blocker
>
>
> So the open questions are ....
>
> ad 2) any quick ideas how to fix that? I will dig though the parent pom
> otherwise ...
>
> ad 3) can we agree an ONE schema which is properly documented - I'm fed
> up with some undocumented guidelines resulting in not enough +1 to get
> commons-exec out of the door, e.g. groupId or versioning. I propose we
> find a common understanding which I put into the commons wiki.
If there are any clarifications to be made, the versioning guidelines
document needs to be updated, not the wiki.
>
> Cheers,
>
> Siegfried Goeschl
>
> Siegfried Goeschl wrote:
> > Hi folks,
> >
> > the next release candidate ....
> >
> > Tag:
> >
> > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
> >
> > Site:
> >
> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
> >
> > Binaries:
> >
> > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
> >
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> >
> >
> > Let the fun begin ...
> >
> > Siegfried Goeschl
> >
> > PS: The test distribution is not part of the release but handy for
> > platform testing -
> > http://people.apache.org/~sgoeschl/download/commons-exec/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi folks,
the current feedback requires a cancellation and a discussion
1) wrong download link in email - was a copy and paste error on my side
2) improved manifest in sources and javadoc jar - seems to be a parent
pom issue and effects all M2 releases (checked commons-cli,
commons-digester, commons-io, commons-jxpath)
3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to
http://commons.apache.org/releases/versioning.html the versioning is
either correct or the docs are wrong
4) missing findbugs-exclude-filter.xml - well, that's a blocker
So the open questions are ....
ad 2) any quick ideas how to fix that? I will dig though the parent pom
otherwise ...
ad 3) can we agree an ONE schema which is properly documented - I'm fed
up with some undocumented guidelines resulting in not enough +1 to get
commons-exec out of the door, e.g. groupId or versioning. I propose we
find a common understanding which I put into the commons wiki.
Cheers,
Siegfried Goeschl
Siegfried Goeschl wrote:
> Hi folks,
>
> the next release candidate ....
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0
>
> Site:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html
>
> Binaries:
>
> http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
>
> Let the fun begin ...
>
> Siegfried Goeschl
>
> PS: The test distribution is not part of the release but handy for
> platform testing -
> http://people.apache.org/~sgoeschl/download/commons-exec/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org