[Top][All Lists]
[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
signature.asc
Description: OpenPGP digital signature
- Re: [Monotone-devel] Release time, (continued)
- Re: [Monotone-devel] Release time, Thomas Keller, 2010/05/28
- Re: [Monotone-devel] Release time, CooSoft Support, 2010/05/29
- Re: [Monotone-devel] Release time, Stephen Leake, 2010/05/28
- Re: [Monotone-devel] Release time, Derek Scherger, 2010/05/28
- Re: [Monotone-devel] Release time, Ethan Blanton, 2010/05/28
- Re: [Monotone-devel] Release time, CooSoft Support, 2010/05/29