shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Gilbert <uid...@google.com>
Subject Re: Proposal To Branch for 1.0 Today
Date Thu, 04 Dec 2008 01:28:40 GMT
Responses below. Again, I don't feel too strongly ("slavish" may be a
slightly strong characterization of my points), but I'm not seeing big
benefits in the short term to major releases independent of spec revisions.

The cost of maintaining a release can easily outweigh the benefits of
releasing a new architecture earlier, when there is likely a spec rev coming
up in a few months. I wouldn't tie down the versions but I do see benefits
in starting with Opensocial Spec Version == Shindig version.

Still happy to support the will of the group on this one - just wanted to
make sure that these points were heard.

On Wed, Dec 3, 2008 at 9:48 AM, Henning P. Schmiedehausen <
henning@schmiedehausen.org> wrote:

> 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.



This seems to be different than your statement bo


>
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message