Danny, > I understood that jakarta version numbers are x.x.x where x is a number, > therefore 2.1 should be 2.1.?
Ok, I guess. Although as I recall, Phoenix 4.0 was labeled 4.0 and not 4.0.0. But 2.1 or 2.1.0 is fine with me. > And since version numbers should always increment for every published > build the released version should be 2.1.2 since we have used 2.1.1 for > betas and release candidates. This I don't agree with. Everywhere I've worked, betas and release candidates did not advance the version number. There's a really good reason for this - In general, you don't know a priori how many betas you're going to have. Thus, you wouldn't be able to settle on a final version number ahead of time. Instead, betas or release candidates are usually marked with the intended final version number followed by a 'b' or 'rc' and the beta/release candidate number. It seems especially undesirable to try and increment the third version digit based on the release candidates considering that, until yesterday, everything that went out was labeled alpha (2.1a1-cvs). We've never actually referred to the release candidates as 2.1.0, 2.1.1, or 2.1.x. In the code they were labeled as 2.1a1-cvs (all versions) and on the web page they were referred to as 2.1a1 followed by a date. Finally, from a marketing perspective, 2.1.2 sounds like a far less important milestone to decimal-centric minds than 2.1.0. As part of the point of this release is to gain some exposure and market James to a wider community, I'd argue that this is a good reason to stick with 2.1 or 2.1.0. Otherwise we risk making our announcement look like a bugfix release. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
