monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Release time


From: CooSoft Support
Subject: Re: [Monotone-devel] Release time
Date: Sat, 29 May 2010 09:30:39 +0100
User-agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)

Thomas Keller wrote:
Am 28.05.2010 15:07, schrieb Philipp Gröschler:
On 28.05.2010 10:23, CooSoft Support wrote:
I couldn't agree more with Thomas's point about Monotone dying if we are
not careful. It's a psychological thing. `Oh it's only at 0.xxx - still
unstable'.
Sure it's psychological and nowadays in the age of OSS, versioning
schemes or rather the progress of their numbers are often not really
expressive. Wine took 10 years to release 1.0 and noone really cared in
the end, because it has been working for ages before. On the other hand
I've seen software for example in a 5.x version and was hugely wondering
what that thing did the four major versions before.

Absolutely right, I don't want to increase the major version every few
months from now on either, but I also don't think we should follow
Wine's example here. Six years are enough :)

People shouldn't look at the numbers of the version but rather on the
feature list on the project's website. Maybe somewhere on that website
there should be included a sentence like "We use it all the time and no
problems so far". Like Jack, I personally use Monotone for all my work
stuff, source codes, server configs, etc. My lady is using Monotone for
her thesis. No problems ever, so count that as +2 from here :-)

Tony mentioned some praise as well, and hey, we even have a dedicated
wiki page to add this:

http://monotone.ca/wiki/Testimonials/

So don't be shy and add your comments there - I'll happily link this
wiki page on the front page!
Lol - I have some time ago. I was the one responsible for the gushing `look no further' comment at the bottom. Sorry, I was just feeling emotional at the time - lol :-). Our SDA was I think responsible for the 11 year old CVS code base one (although he is keeping quiet about it!). Hehe.
One problem of a 1.0 or 1.0.0 release could be, that the more
sophisticated users from bigger development groups, which then start to
use monotone because of the major release, often stick to a version they
chose in the beginning of a project. Of course they still want to have
bugfix releases, but by no means they want breakage in the API or
interface or whatever applies.

I've seen this happen on another project I accompanied a while ago. As
soon as they put out 1.0 there only came bugfix releases afterwards,
although many requests for mostly the same improvements appeared on the
mailing list and the excuse always was like "No we don't do that,
because then we would break with the big guys". Does Monotone have the
power to support two branches, so that new and needed features don't get
stalled?

For that to happen we'd need to have more of these "big guys" in first
instance - and I'd love to support them all. From a management point of
view I don't care if I handle one single branch or two, a stable and a
feature branch, or whatever works for them.

Thomas.

------------------------------------------------------------------------

_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]