release updates and roadmap discussion

[Matt Ingenthron]

Hi all,

Since a number of memcached contributors and client authors were in one
place at the Drizzle conference this week in Seattle we had a short
discussion about the release roadmap for stable and development
branches. I captured much of the discussion and it's posted on the wiki:
http://code.google.com/p/memcached/wiki/DevelopmentRoadmap

It is prefaced with dormando's proposed release cycle, which I think
myself and Dustin have replied to. The roadmap items are also in a
proposal state, so if you have any thoughts, work you have in the
pipeline or things you'd like to see, please jump into the conversation
here on the list.

Thanks,

- Matt

[Mark Atwood]

Also discussed is eliminating the "even/odd" release numbering system.

I propose instead that we keep the main tree usable and stable and
passing all tests at all times (like Drizzle does), and development
and expermental features be in their own independent branches, and
they get merged into the main branch as they stablize.

Couple that with regular releases (every 2 weeks?), and get rid of
the "1.4 vs 1.5" discussion entirely.

--
Mark Atwood <http://mark.atwood.name>

[Dustin]

On Aug 20, 12:19 pm, Mark Atwood <m...@mark.atwood.name> wrote:
> Also discussed is eliminating the "even/odd" release numbering system.

I don't have a huge opinion here. I just want it to be obvious
which releases are newer than others (feature-wise).

> I propose instead that we keep the main tree usable and stable and  
> passing all tests at all times (like Drizzle does), and development  
> and expermental features be in their own independent branches, and  
> they get merged into the main branch as they stablize.

We work really hard to ensure that master is always well-tested
code. We don't push code there that doesn't build on all of our first-
class supported builders (having some problems with OpenBSD, but that
is hopefully to be first-class soon).

[Clint Webb]

To be honest I only care a little bit, and neither choice would affect me much, but I do not prefer the even/odd system.   I think it promotes larger gaps between releases, and much harder to get quick patches in. 

My preferred method when working on projects like this... is to look at the todo list... pick the top number of items that would take about 2 weeks to do, and assign those to the next potential release...  When those items are done (even if it takes more than the estimated 2 weeks), release them and any other (critical or not) patches that happened to come in during that time (and were tested).   Test the release as a whole, and release it.

Rinse and repeat.

I'm hardly active in the memcached development though, so my opinion has very little value.  :)

PS: I am a Release Manager in real life.  :)

--
"Be excellent to each other"

[dormando]

Hey,

I wasn't really intending on doing another 1.3-like series. Since the new
protocol was a Big Deal and a Forward Standard we had to give it a lot of
time and a few good public revisions before solidifying on it. I don't
think any of our forward internal changes really require this.

1.5 would thus be another fully stable tree but with some significant
change. The tree reorg and/or engine support are probably worth that bump.

We should be able to keep the release cycle on this nearly consistent
schedule and slowly filter in these more major changes.

For example:

1.4.2 - more minor feature enhancements, build fixes, bug fixes
1.4.3 - tree rewrite
1.5.0 - engine merge
1.5.1 - regex expire or whatev.
1.5.2 - engine fixes, la la la.

... in the meantime, as we work on 1.4.2, and filter in these changes, the
target for 1.5.0 should get more public scruitiny. Posts on the mailing
list to review/play/design against the API, etc. That, in my opinion, will
obviate the need for a development series of releases.

The above is an example. If everything looks okay with the engine code
it's entirely plausible for 1.4.3 to be skipped.

Thoughts?
-Dormando

[Trond Norbye]

dormando wrote:
> Hey,
>
> I wasn't really intending on doing another 1.3-like series. Since the new
> protocol was a Big Deal and a Forward Standard we had to give it a lot of
> time and a few good public revisions before solidifying on it. I don't
> think any of our forward internal changes really require this.
>

+1

> 1.5 would thus be another fully stable tree but with some significant
> change. The tree reorg and/or engine support are probably worth that bump.
>
> We should be able to keep the release cycle on this nearly consistent
> schedule and slowly filter in these more major changes.
>
> For example:
>
> 1.4.2 - more minor feature enhancements, build fixes, bug fixes
> 1.4.3 - tree rewrite
>

The tree rewrite isn't really needed, but I think it would make a more
clean view of the internal modules.

> 1.5.0 - engine merge
> 1.5.1 - regex expire or whatev.
> 1.5.2 - engine fixes, la la la.
>
>

Sound good to me.

Trond