shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Brown <e...@google.com>
Subject Re: Proposal To Branch for 1.0 Today
Date Thu, 04 Dec 2008 01:42:03 GMT
On Wed, Dec 3, 2008 at 5:28 PM, Evan Gilbert <uidude@google.com> wrote:

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


Other than being what every other software project that anyone actually
cares about does, yeah, no big benefit. So that gives us:

Match spec versions: Some people who can't read release notes will still
know what version of the spec is supported. They won't know whether or not
they're dealing with a compatible upgrade, if they have to recompile, or if
their interfaces are even going to work, but at least they'll know that the
code claims to support an arbitrary version of the spec.

Don't match spec versions: Follows a proven engineering practice used by
successful software projects for over half a century.


> 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