commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Cancellation of commons-exec-1.0.0 (RC4) vote ....
Date Tue, 24 Feb 2009 22:45:53 GMT
On 24/02/2009, Siegfried Goeschl <siegfried.goeschl@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 <siegfried.goeschl@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.goeschl@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


Mime
View raw message