[EMAIL PROTECTED] wrote:
> On Oct 9, 7:17 pm, Christian Boos <[EMAIL PROTECTED]> wrote:
>   
>> Christopher Lenz wrote:
>>     
>>> I must say that I'd consider that kind of change/vision outside of
>>> the scope of even Trac 1.0.
>>>       
> ...
>   
>>> We will need to sort this out *somehow* for the future. Here's what
>>> *I* want: us to release a 1.0 version sometime in this decade, and
>>> postpone any big vision shifts until after that point.
>>>       
> ...
>   
>>> What I want is to fix the big problems we still have, for example
>>> I18n or documentation/help. I don't yet want to think about multi-
>>> project support, a generic resource system used throughout the code,
>>> or big changes to the plugin/component system.
>>>       
>>> There's a life after 1.0, if we even ever reach that point.
>>>       
> ...
>   
>> Well, multi-project support has always been a 1.0 goal, for one.
>> Improved change notification is a topic for 0.12, I think (#1890 and
>> the like). But we'll have other occasions to talk about all this...
>>     
>
> what do you think about adopting a model like git development, who
> release/tag very often, say every 2 weeks or one month. see
> http://repo.or.cz/w/git.git?a=tags for their tag history, and here for
> their branch/merge history: 
> http://repo.or.cz/git-browser/by-commit.html?r=git.git
> .
>
> what version would be called 1.0 should not matter imo, we are using
> it since one year productive, stable and with great pleasure so nobody
> would complain about calling 0.10 1.0. and also after 1.0 there may be
> incompatible changes, thats life that somebody may come up with a
> better idea how to do something.
>   
1.0 is a statement about API stability. At that point we need to be
really sure internals aren't going to change. Thats hard. So yes, it
matters.

--Noah

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to