monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Release time


From: Thomas Keller
Subject: Re: [Monotone-devel] Release time
Date: Fri, 28 May 2010 15:53:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.4

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!

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

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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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