shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <henn...@schmiedehausen.org>
Subject Re: Proposal To Branch for 1.0 Today
Date Wed, 03 Dec 2008 17:48:01 GMT
Evan Gilbert <uidude@google.com> writes:

>On Tue, Dec 2, 2008 at 6:31 PM, Henning P. Schmiedehausen <
>henning@schmiedehausen.org> wrote:

[...]

>> Evan Gilbert <uidude@google.com> writes:
>> >This may be a little different than other cases because our major Shindig
>> >revisions will be very closely tied to spec revisions for a while to come.
>> I
>> >don't think this is often the case.
>>
>> What makes you think that this is the case?


>The velocity of the spec means there's much less incentive to create a
>release branch between spec revisions.

Ok, so here is a thing that I don't understand: 

You might make a "release branch for a spec". But that does not mean,
that you "only release once from that branch and there is only one
release per spec release". This is an Apache Project. Not a RI for a
JSR. 

And I very much hope that this is (and will be in the future) a
living, thriving project. Looking at other Apache projects, that
usually means that there are one or two versions of the project in
active support (let's call them 1.x for Spec A and 2.x for Spec B) and
the (usually unstable) trunk where new stuff is tried out, tested and
worked on.

So the project has 1.x in maintenance mode, where the occasional bug
fix and security patch is applied. 

2.x is stable but people are still trying out new stuff like new
implementations or refactoring of the existing code. This might lead
to branches off the that code (again, let me cite Tomcat here: the
Tomcat 5.0 vs. 5.5 case) but nothing much beyond the frame given by an
existing spec happens here (you might still have add-ons that extend
the functionality but don't break the spec. They usually live in a
"contrib" like tree). And you would be surprised, how many people
will actively contribute to an existing version of a code base, even
if it is framed by a spec, simply because they have built a
business/run a ton of servers/have put an application on top of that.

And there is the trunk.  Ahh, the trunk. This is where the cool kids
hang out. Where new stuff is forged. Usually unstable, breaky, leaky,
might not even compile. Stuff is put in, thrown out, tossed
around. But whenever you feel, that this code is *architecturally
sound*, you branch off the trunk into a release/maintenance branch. Or
when you really follow a spec closely, you branch off if you feel that
there is only polishing/stabilizing needed to implement that spec. 

I fully expect Shindig to do a lot of releases from its release
branches. Even if the trunk is further ahead feature wise. 

And I fully expect most bug reports coming in to be against the
release branch, not the trunk. On the trunk, you have the early
adopters and the "I know how to svn up/mvn install" people. 

On the release branch, you get everyone else. If you don't release,
you lose everyone from the latter group. Once there is a second
implementation of the spec (and I would bet that there will be at
least one more within 12 months), you will lose these people. 

I want Shindig to release often. Early and often. This is how you
close the feedback loop to the users. And I want to have 1.0.1 and
1.0.2 and 1.0.3 and 1.1.0 and 1.1.1 follow the 1.0.0 maybe spaced only
by a couple of weeks or months. There is no point in *not* doing
it. Apache releases require no lenghty QA cycles. If the developer
community feels that it is ready, you gather three +1 votes, wait 72
hours and put that thing on the mirrors. If it is a brown paper bag
release, you release a patch release two days after this.

So please, and that is the point I'm trying to make, please *LOSE*
that slavish clinging to the spec release versions. The spec is made
outside Apache and its release cycles are not controlled by
Apache. Shindig implements the spec when it is released. That is the
only relationship that is needed (and IMO wanted). Similar to all the
specs that other Apache projects implement.

        Ciao
            Henning

-- 
Henning P. Schmiedehausen - Palo Alto, California, U.S.A.
henning@schmiedehausen.org "We're Germans and we use Unix. 
henning@apache.org          That's a combination of two demographic groups
                            known to have no sense of humour whatsoever."
                               -- Hanno Mueller, de.comp.os.unix.programming 

Mime
View raw message