Hmmmm... This is a tough one, but I would think that a version scheme change discussion might be in order. It might be fruitless, but I think that type of versioning is pretty rough. Plus, there are nearly zero docs anywhere about it, not just with Struts2, but also with the Tomcat and httpd. Plus, I could probably safely state that 95% or more of all OS projects use the other model for versioning.Oh, I don't know. Aside from HTTPD and Tomcat, it's also used by MySQL and many, many others. It's less noticeable once there's been a GA release, and the subsequent builds tends to go GA as well. In a few more years, I'd expect that this will become the dominant open source release system. The process is very straight-forward. Here's a paragraph from our bylaws: "After a proposed release is built, it must be tested and classified before being released to the general public. The proposed release may be assigned "Alpha", "Beta" or "General Availability" classifications by majority vote. Once a release is classified by the PMC Members, it may be distributed to the general public on behalf of the Foundation. Distributions may be reclassified or withdrawn by majority vote, but the release number may not be reused by another distribution."
This is probably a religious thing and probably not worth going into too much just because some newcomer didn't like it ;) However, looking over all the projects I used during my last sizable project, looks 90% of them used the other approach. These are: asm, cobertura, easymock, junit, spring*, acegi, activation, google apis, axis, bluprints, cglib, commons* (I think), dom4j, jdom, freemarker, oro, java-net-commons, joda-time, log4j, lucene, xwork and a 2-3 others. So, as a Java developer heavily using OS, I seem to have a different perspective. BUT, I'm also intelligent enough not to make a huge deal out of it AND I'm not really in a position to do so. Just feedback from the outside looking in mostly.
I think what I meant as dead is that you can't use them in production because they are not fully functional and tested. So, if I stumble across a 2.0.5 JAR floating about somewhere, I have no idea that 2.0.5 is actually broken to some degree because the version appears to be the 5th patch from the final release of 2.0. Again, I'm reading into this the versioning that I'm used to and that other projects use. That is where the main confusion comes from. Where on the other hand I stumble across a 2.0.0-beta5 JAR floating about, I immediately know that it is not production quality yet just from the naming.One more thing is that the versioning scheme doesn't appear to be followed because 2.0.2-2.0.6 aren't available for download in anything but a snapshot version. If the model is that all "releases" receive a version than these should be available to download unless what you are saying is that some test builds never get released and therefore those version numbers become effectively dead versions. Personally I try to avoid dead versions numbers whenever possible.All builds receive version numbers, but not all builds graduate to public releases. The versions aren't dead, they just didn't make it past a test build. We use these same numbers in the JIRA tickets and notes, so it would be hard to simply bypass versions. Even though the builds are make public, many people still test them with us, and we refer to something being fixed or changed in 2.0.3 or 2.0.4. Again, this is only noticeable because we haven't been able to issue a GA release yet (mainly because our key dependency, XWork, only cam out of beta itself in January).
Anyways, just some observations about versioning in general I guess... -bp
smime.p7s
Description: S/MIME Cryptographic Signature
