Danny Angus wrote:
> By accident this happens to be 2.1.1 not 2.0.0, and I think we are stuck with it.This I don't agree with.You're right, and on re-reading I should've said.. it should be 2.1.1, as we've been using 2.1.1 from cvs, and this is considered to be the release cvs is working towards. There is a strict rule that numbers *MUST* increment, we've had this dicsussion before and consider that cvs version number is the release we are working towards.
The CVS tag *MUST* increment. The tag must also reflect the "marketing" version.
I do *NOT* agree that the tag /should/ be 2.1.1! As mentioned previously in this thread, the tags up until now should have been named 2.1b1, 2.1rc1, etc. If "by accident" the current tag is 2.1.0, then that is bad management. However, if we are stuck with bad management, then the prime directive must apply - the version number must increment.
Absolutely not! Everywhere I go I find myself re-vamping the build/release management process. I all cases, the CVS tag *MUST* be kept in sync with the public release version. If not, keeping track of which release matches which version becomes a nightmare! The use of b1, b2, rc1, rc2, etc is a the only way I have found to achieve this.Our announcement can be that we are releasing version 2 or 2.1, as long as the tag and filenames are 2.1.1.
At the end of the day, the released version *must* match the tag in CVS. The version tag *must* increment with each build that is made available outside of the development community. If the combination of these factors dictates that the current version be 2.1.1, then that is how it must be.My point is that I think we are stuck with the full internal (c.f. marketing) version number being 2.1.1 (or higher)
If that is the case, however, then the release management process must be improved for next time. 2.1.1 /ought/ to be a bugfix release. 2.1.0 is the appropriate number for as important a release as the current one.
Has our release version already been sent out in our press releases? If so, then that would have to override any internal management concerns. Keeping one's commitments to the client (in our case, the public,) is of paramount importance in *every* IT project. Swallowing the bitter pill of compromise is the price of bad management.
There you have it. My tirade is over. My feelings are known. Do what you must.
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
