On 14 February 2010 15:23, Simon Large <simon.tortoisesvn_at_googlemail.com> wrote:
> On 14 February 2010 07:35, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> On 13.02.2010 22:36, Stefan Fuhrmann wrote:
>>>
>>> My preferred solution would be switching to an
>>> entirely different scheme: Make the initial release
>>> year the main version number, i.e. "2010.0.0".
>>> People are used to that scheme and it would
>>> clearly signal independent versioning with saying
>>> "detachment".
>>
>> I like that idea. And it even allows to keep a 'stable' number.
>> So '2010' would be the major number, the second one the minor number,
>> allowing us to ship new features, and the third one would be used to
>> ship bugfixes.
>
> I like the clear break in numbering scheme. I am less keen on linking
> to a year. If we do a major release in December 2010 and then just
> bugfix releases for 6 months, we will be shipping 2010.x.x well into
> 2011 which doesn't look good. Microsoft stopped using their
> year-related operating system names quite quickly, I guess because in
> 1996 Windows 95 just sounded out of date. And if we change it to 2011
> anyway then there is no clear indication that the 2011.1.2 is just a
> bugfix of 2010.1.1
Replying to myself here. MS are still using dates in their office and
compiler products, so ignore that previous comment.
More options listed here:
http://en.wikipedia.org/wiki/Software_versioning
If we use a date then it should of course reflect the stable branch
date, not the release date. Of the date schemes I quite like Ubuntu's
8.10 representing the October 2008 branch. And it is (a bit) less
obviously just a date, nor is it a very large number. So the next
release of TSVN could be 10.3.0.18999
> I think the most significant number(s) should indicate compatibility
> in some way, which I think the year scheme does not do.
>
> Yet another scheme would have SVN.TSVN.Bugfix.Revision or perhaps
> better, TSVN.SVN.Bugfix.Revision.
>
> 10.106.3.18345
>
> TSVN stable branch 10 (we can start this from any number which is
> obviously different from 1)
> SVN stable branch 1.6 (the 0 is because it may go to 1.10 before it gets to 2.0)
> Bugfix release 3
>
> The TSVN branch will be incremented when we make a mid-term release
> and also when subversion makes a release because we normally release
> whatever new features are in trunk at that time.
>
> So, first number is TSVN features, second is subversion library/WC
> compatibility.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447433
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-14 17:07:07 CET