Re: [Monotone-devel] Release time

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> After all we should all agree that monotone has been proven stable for
> many, many versions now and that we (the original and today's
> developers) should be proud of it, so proud that we should dare to put a
> proper version label on this darn thing.

+2 :).

>> BTW, a minor suggestion: if the next release is 1.0, perhaps this
>> would be the time to switch the versioning scheme? 1.0 implies
>> stability, so people will be surprised if there are major changes
>> between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala
>> Linux kernel would make it easier for users to see which were small or
>> bugfix releases (1.0.4->1.0.5) and which were larger (1.0.5->1.1.0).
>> (OTOH one could represent larger changes by going to 2.x, 3.x, ...  as
>> well, so I suppose this is a bit of bikeshedding)
>
> I agree that continueing the current versioning scheme, just with a
> prefixed "1.", won't make much sense any longer, but I'm against
> complicating this too much. A new easy rule for now could be:
>
> 1) if a release only consists of bug fixes or has small, not BC-breaking
> improvements (esp. in respect to automate), raise the patch release
>
> 2) if a release has bigger improvements or breaks BC, raise the minor
> version
>
> 3) if a major flag day introduces major new things or we've rewritten
> 90% of monotone (:)), raise the major number.

+1

-- 
-- Stephe