[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [RT] Are svn externals a good idea?
From:       Ralph Goers <Ralph.Goers () dslextreme ! com>
Date:       2005-09-28 13:54:10
Message-ID: 433AA082.6000401 () dslextreme ! com
[Download RAW message or body]

I have to say I agree with pretty much everything in your message.  I 
like the premise of it as it makes us assume that as soon as code is put 
out there that it is being used. In my opinion, this creates a much more 
customer oriented mentality because you are going to get yelled at a lot 
when you start breaking compatibility.

Ralph

Daniel Fagerstrom wrote:

> Jorg Heymans wrote:
>
>> Daniel Fagerstrom wrote:
>>  
>>
>>> For 2.1.x (that we hopefully will kill soon), we could do something   
>>
>> 99.99% of our userbase is using it, no need to make them jump out of the
>> window with statements like this ;)
>>  
>>
> What we have discussed on the list and seem to an agreement about, is 
> that we will try to release a last (or something like that) relase in 
> the 2.1.x series after the GT. Then we will also release a 2.2 alpha. 
> During the alpha stage of 2.2, early adaptors will hopefully identify 
> all unplanned incompabilities so that we can correct them. And for 
> planned incompabilities we will provide migration instructions. The 
> 2.1.x will not be killed until we can offer a stable 2.2 (or maybe 
> later than that).
>
> After 2.1.x we will hopefully be able to have binary releases and 
> separate release cycles for all blocks. This will make it easier to 
> make new releases, and easier to  keep instalations up to date. It 
> will also increase the preasure on keeping stable contracts on blocks.
>
> We will hopefully be able to abandon our current use of "global" 
> branches. There will be just one trunk version on nearly all of the 
> blocks. New functionality will either be introduced by creating a new 
> block, within an existing block or if it is impossible to avoid by 
> having a development branch of a specific block.
>
> As I have discussed before "stable" branches doesn't lead to stability 
> as one might believe. Software becomes stable when many people use it. 
> By calling something an unstable branch it will become unstable as 
> none use it. It is better to just have a trunk and develop in an 
> incremental and evolutionary way. In this way trouble will be detected 
> early when it easy to fix. It will also motivate us to have so much 
> automatic testing that the trunk will be stable.
>
>                    --- o0o ---
>
> I use drastic formulations like the one above because I'm impatient 
> and want all the new goodies right away ;)
>
> I don't think users have to worry, rather the oposite. We are heading 
> towards a less monolithic and more scalable Cocoon, that will be much 
> easier to maintain and to keep up to date.
>
> /Daniel
>
[prev in list] [next in list] [prev in thread] [next in thread]