So essentially it's
ARCH.MAJOR.MINOR.PATCH or REWRITE.MAJOR.MINOR.PATCH
insofar as the Architecture of 5 is different from 4, though the
concepts are related.
I don't know, I just see minor and patch to be somewhat too closely
related, or at least they should be. 5.1.1->5.1.2 could be a bugfix
or an implementation change if it is purely internal or has no API
impact, 5.1.x -> 5.2 would be API additive, but could also be a bugfix
or a feature. 5.x -> 6.x just wouldn't happen. I think this is
possible as long as .z level features don't stew in the pot too long
and releases are reasonably regular. The only difference would really
be that a bugfix might result in a quick shuffle to release sooner,
possibly even grabbing from a previous tag and branching to get the
fix out sooner so as not to polute the "fix" with new code, then just
rev the snapshot version currently on the trunk and merge the isolated
change in if it's still relevant. There's not a huge core-committers
list here, so I'm thinking it's manageable.
Christian.
On 19-Feb-08, at 18:21 , Ulrich Stärk wrote:
I think http://commons.apache.org/releases/versioning.html is a good
guide to what I mean and it doesn't seem that uncommon at the ASF
(from a quick scan at least Struts, commons and OpenJPA use it). The
only difference is that we prepend 5 to the major number.
Uli
Ulrich Stärk schrieb:
I agree that my proposal demands some discipline from the developers.
But as a user I want to have new features and improvements now. And
not with the next stable release. And I want to have them without
having to rework everything I have done so far. (You know, we are
like children :-))
I once learned that time to market of a product is crucial for its
success. When you always wait with new features until the next
stable release and then also reserve the right to introduce API
incompatibilities within that same release you are forcing your
users to either use unstable software or drive them away completely
to one of your competitors.
I really urge you to weigh up the effort needed to coordinate a
small bunch of developers against the benefit of being able to
release new features with the guarantee to not introduce API
incompatibilities.
5.MAJOR.MINOR.PATCH is my favorite with MAJOR changing when
introducing API incompatiblities and MINOR when adding new features.
Uli
Kevin Menard schrieb:
While I can appreciate that the kernel devs found the odd/even
didn't
work for them, as a user I appreciated it more.
That's neither here nor there, though. From a pragmatic standpoint,
the A.B.C.D scheme, aside from being really long, makes POM
management a pain. If Howard has one idea of what he's going to do
next and I have another and Ted has a totally different one, we'll
run into people bumping B, C, or D. At best you end up with a bunch
of confusing version bumps. At worst, someone forgets to make the
bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing
an API incompatibility that should have really been in
5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to
breakage, but they shouldn't be so foolishly.
If these concerns can be allayed using another method, I'm open to
it. As I've said earlier, it's a non-trivial matter to consider, so
the more quality suggestions, the better.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
