[starksm64]

So there are two issues here. The first is a fine grained description of a version using all four fields and the other is to what degree version compatibility is expressed. Essentially eclipse is not using the qualifier portion of a version in any version expressions so the value of the qualifier string becomes irrelevant in terms of compatibility. This makes sense as having to specific binary compatibility to the precision of the qualifier indicates a completely broken release stream for a given x.y.z.q for a given x.y.z once q is beyond a given level. There is the issue of initial releases (alpha, beta) not being able to guarentee a stable API, and misuse of RC levels of stability (ejb3 has been RC for months without a final spec) that we need to sort out.

We still need to have a convention for the qualifier and make use of it to clearly define releases.

From http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning with the conventions updated to use the x.y.z.q format, and Final changed to GA (which I like better):


X.Y.ZZ.DR# - DR stands for Development Release. There could be a number of development releases. For example jboss-4.0.0.DR1. A development release is a significant project milestone, but it does not implement all of the key features targeted for the public release.
X.Y.ZZ.Alpha - An Alpha release includes all key features and is passing the main test cases. It still needs work on edge cases, bug fixes, performance tuning and other optimization tasks.
X.Y.ZZ.Beta - A Beta release is the first release that the development and QA teams feel comfortable releasing for public testing. Some bug fixes and minor optimizations are expected, but no significant refactoring should occur. No new major features are introduced from this phase on. Only stabilizing work.
X.Y.ZZ.RC# - Each release candidate is a potential target for final release. Only if unexpected bugs are reported during the iteration timeframe the RC number is incremented (e.g. jboss-4.0.1.RC1 to jboss-4.0.1.RC2) and another release candidate is published. Generally only minor bug fixes are introduced to code and documentation.
X.Y.ZZ.GA - A Final version is released when there are no outstanding issues from the last RC version. Usually it's a matter of renaming the version from RC# to Final and repackaging the software, (jboss-4.0.1.GA).
X.Y.ZZ.SP# - A service pack release to a final release. A service pack may be made when there are significant issues found after a final release to provide a bug fix release before the next scheduled final release, (jboss-4.0.1.SP2).


Does this work?

[mculpepper]

1. X.Y.ZZ.DR#
2. X.Y.ZZ.Alpha
3. X.Y.ZZ.Beta
4. X.Y.ZZ.RC#
5. X.Y.ZZ.GA
6. X.Y.ZZ.SP#

With this definition, wouldn't a GA release be seen as an "earlier" version than a RC release?

[starksm64]

I'm still looking for the full semantics of the eclipse download version check. If its just the osgi bundle version in the eclipse framework, then the qualifier would need some numeric prefix that enforced the proper ordering. The qualifer format could be something like:

id-XX# (e.g., jboss-4.0.4.200601202032-Beta)

where id could be a build id, a timestamp, etc. It just needs to be consitently increasing for a given x.y.z release. For jbossas I would use the current YYYYMMDDHHSS GMT build timestamp (e.g., 200601202032) so that even consecutive builds of the same qualifer would be increasing.

[acoliver]

I do not intend to change the versioning for JBMS until after the 1.0 release as inconsistancy inside of JBMS releases would be more disruptive than would being out of compliance with whatever versioning proposal. However, after 1.0...just make it clear and reasonable and then I don't really care so long as I don't have to think real hard or be in regular discussion about it.

[belaban]

I have to use *all numbers* for JGroups because I'm sending the version as a short with every message, and I actually do a comparison so I can discard messages from different versions.

[mculpepper]

I'm still looking for the full semantics of the eclipse download version check

AFAIK Eclipse is using osgi's version comparison. The "timestamp" versioning idea is a good one, but it presents a small problem for the IDE as all plugin and feature directories contain the full version in the name, i.e...

eclipse/plugins/org.jboss.ide.eclipse.core_1.5.0.200601220345-GA

I don't see any other way around the problem though, than just using a simple 1,2,3 prefix which seems like more than a hack than providing real information. So this is probably the best solution.

I have to use *all numbers* for JGroups because I'm sending the version as a short with every message

Couldn't you just ascii-code-ize the RC/GA/whatever?

[starksm64]

I have to use *all numbers* for JGroups because I'm sending the version as a short with every message, and I actually do a comparison so I can discard messages from different versions.

Can't this be a deriviate of the full version? Getting back to the binary compatibility constraints, I don't expect that one should have to specify compatiblity beyone the x.y.z level. So, for a jgroups-2.3.0.*-GA, only 2.3.0 is relevant to the wire format compatibility check.

[starksm64]

Some alternatives to try to avoid a numeric prefix qualifier include dropping the DR as it adds little to an alapha release.


Rely on the UTF-8/ASCII upper/lower case ordering and use lower case for ga/sp to ensure they come after RC:

1. X.Y.ZZ.Alpha#
2. X.Y.ZZ.Beta#
3. X.Y.ZZ.RC#
4. X.Y.ZZ.ga
5. X.Y.ZZ.sp#

Change RC to C(andidate for )R(elease):

1. X.Y.ZZ.Alpha#
2. X.Y.ZZ.Beta#
3. X.Y.ZZ.CR#
4. X.Y.ZZ.GA
5. X.Y.ZZ.SP#

[sebersole]

silly, but for the sp, RC, Beta, and Alpha would also need to be careful about limiting the full compilment of such atrtifacts within a given release since most character sets interpret 'sp10' before 'sp2'.

[sebersole]

plus since you mentioned antlr-2.7.5H3, how should we handle thirdparty libraries which we temporarily patched ourselves? how do they fit into the versioning scheme?

[starksm64]

plus since you mentioned antlr-2.7.5H3, how should we handle thirdparty libraries which we temporarily patched ourselves? how do they fit into the versioning scheme?

For thirdparty stuff we should just use a version convention:

antlr-2.7.5.SP1-Hibernate

or similar. All that matters is that we can increase the version consistently if we have to do another patch/service pack in this release.

[starksm64]

silly, but for the sp, RC, Beta, and Alpha would also need to be careful about limiting the full compilment of such atrtifacts within a given release since most character sets interpret 'sp10' before 'sp2'.

Yes, good point. So really we would need a fixed width convention that would cover the maxinum level of rev for a given qualifier, sp02, sp03, sp10. We have yet to get beyond 4-5.

[mculpepper]

I think I like the "Candidate for Release" idea... , but what would we do for preview / developer releases?

[starksm64]

preview/developer releases are alphas and betas. We don't need an infinite number of qualifiers so I'm saying the DR devloper release is to be dropped as its just an alpha or beta depending on its stability.