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.
------------------------------------------------------------------------
_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel