Aaron Knauf wrote:
I agree with Aaron. Its the tag that needs to be changed not the number.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.
Also, it would be very confusing to have the cvs tag different from the 'name' tag.
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.
Our announcement can be that we are releasing version 2 or 2.1, as long as the tag and filenames are 2.1.1.
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.
Agree. Version 2 was released ages ago - called 2.0
What is in cvs is a major release so it should be 2.1. If we have really mucked up the numbering somewhere then we should call it 2.2 - but not 2.1.1 or 2.1.0. The third number should only be for bugfixes or really minor additional functionality.
Charles
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
