[SM-DEVEL] Release planning and the future!

[Rick C. <ri...@sq...>]

     First of all... you guys rock!  1.2.6 will be a significant
     improvement over 1.2.5, and it's your hard work that has made
     it so!

     We've been talking about releases recently, and as a team,
     we agree that we need to release more often.  To do so, we're
     going to work on release planning.

     For each release in the stable series, we'll be choosing
     1-3 new features to add to the codebase, as well as the usual
     bugfixes and performance improvements.  The stable team leads
     will coordinate the decision on what features will go into
     each release, with input from everyone.

     Jason, Wouter, and Konstantin are the stable team leads, and
     will be discussing this in greater detail once 1.2.6 is out
     the door.  I'll be helping them pull together feature requests
     already existing in the SourceForge site, the wiki, and the
     mailing list archives, and documenting it all.

     We're all really excited to see so much enthusiasm and so
     much coding going on!  Keep up the great work, and we'll do
     our best to keep things organized and rolling along!

     -Rick
     ri...@sq...


Michael Douma said:
> Now that 1.2.6 is almost out the door ... great work guys! ... some
> comments about branches...
>
> First of all, there are so many features in 1.2.6 that bugs *will* be
> found. Since we don't have a big QA team, this is inevitable. Those
> should be promptly resolved in the next 1-2 weeks in 1.2.7.
>
> Now that a new version cycle is beginning, I would encourage revising
> the branches. I agree with Thijs that there has been some mishmash
> between modest improvements and serious R&D. We've got great additions,
>  but at the expense of delaying modest improvements. I am too ignorant
> of  CVS to recommend a practical solution, but it seems that there
> should be  three tracks/branches:
>
>   a) A release-often track, with modest improvements.
>
>   b) An R&D track, for significant additions that will take
>   considerable
> time to perfect. Threading, caching, are good examples.
>
>   c) A nascent ZK track, for modularity issues.
>
> What do Paul and the senior management think? Do you think it is time
> for more division? I don't know, but it would be nice to reduce the
> time  between releases.
>
> Michael
>
> -------------------------------------
>
> On Friday, April 26, 2002, at 03:29 PM, Konstantin Riabitsev wrote:
>
>> On Fri, 2002-04-26 at 15:15, Thijs Kinkhorst wrote:
>>> Hello all,
>>>
>>> Don't misunderstand me - I greatly appreciate all the work put in by
>>> the
>>> various SM developers - but what happened to Release-Often? I thought
>>>  SM
>>> was following this paradigm but it seems not.
>>> The release of 1.2.6 keeps being postponed. It includes many very
>>> useful
>>> fixes but it still isn't on the site because the release keeps being
>>> delayed. For example Marc's speed improvement patches are great work,
>>>  but
>>> why not release 1.2.6 *now* and within a short term release 1.2.7
>>> which includes those patches in stead of again delaying the release
>>> yet  again? I
>>> think this is just what release-often means.
>>> It has been more than two months since the last release. 1.2.6
>>> contains many fixes for common problems with 1.2.5. Get it out,
>>> please! :-)
>>
>> I am currently (as we speak) fixing cross-site-scripting
>> vulnerabilities. That has hindered us, but hopefully once this is in
>> we will be able to release 1.2.6pre1. pre1 is necessary so translators
>> can update strings.
>>
>> No, we cannot release something that contains known security flaws.