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 <siegfried.goes...@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 <siegfried.goes...@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-unsubscr...@commons.apache.org
>>>  >>  > For additional commands, e-mail: dev-h...@commons.apache.org
>>>  >>  >
>>>  >>  >
>>>  >>  >
>>>  >>  >
>>>  >>
>>>  >>  ---------------------------------------------------------------------
>>>  >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  >>  For additional commands, e-mail: dev-h...@commons.apache.org
>>>  >>
>>>  >>
>>>  >>
>>>  >
>>>  > ---------------------------------------------------------------------
>>>  > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  > For additional commands, e-mail: dev-h...@commons.apache.org
>>>  >
>>>  >
>>>  >
>>>  >
>>>
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to