Re: [Monotone-devel] Release time

[Thomas Keller]

Am 27.05.2010 18:54, schrieb Jack Lloyd:
> On Thu, May 27, 2010 at 09:38:32AM +0200, Thomas Keller wrote:
> 
>> Apropos release - a fellow developer reminded me that we *might* want to
>> set a proper release number for the next release (you know what I'm
>> talking about, 1.0...) - given the fact that we're still recognized as
>> "alpha" software in a couple of places. What do you think?
> 
> Just for the sake of argument:
> 
> While 1.0 is good for a public image perspective, is it something that
> you want to lock yourself into?
> 
> I can think of a few things that might potentially happen that might
> be harder to pull off post-1.0:
> 
>  - s/netxx/asio/
> 
>  - netsync over TLS
> 
>  - policy branches (or some equivalent change; mtn's inability to do
>    proper per-branch security is actually a big problem for me - it
>    makes me nervous giving out write access to public projects,
>    because while I'd be fine giving some random person write access to
>    some particular subbranch that I could pull changes from, I
>    wouldn't want them to be able to scribble elsewhere, even by
>    accident. Limitations in this area also make me nervous about
>    putting branches that have to remain private/secure on my public
>    mtn server).

Other people already responded here, just my 2 ct:

I've just recently stumbled across your TLS feature request in the
tracker from 2006 and simply put, if there was just not enough man power
to do that until now, I don't think it will happen until 1.0 either (if
1.0 should be out this year or beginning of next year). The same is true
for policy branches (which recently saw more development though, thanks
to Tim) and the replacement of netxx (what we should not only do for
cosmetic reasons, but also for better IPv6 support).

My main point is: We need more users! More users means more development
(directly because of feedback and eventually indirectly because of more
submitted patches). And I fear that if we only ever think in small steps
and improvements like in the years before, this project will probably
die off in the future silently because it won't get noticed and fewer
and fewer new people will hack on it. This is why I started to blog more
about monotone in my personal blog and why I syndicated it on monotone's
home page. To generate more more interest, more buzz, more traffic.

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.

Jack, don't get me wrong, all the above mentioned features are surely
important (and I'd love to see them implemented), but I don't think they
should block 1.0 any longer.

> 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.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature