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]
