shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
Date Mon, 15 Jan 2007 18:53:21 GMT
On 1/15/07, Greg Reddin <> wrote:
> On 1/15/07, Kailas Lovlekar <> wrote:
> >
> > >Shale is listed at version 1.1.0
> > All the pom.xml files show "1.1.0-SNAPSHOT", not sure how 1.0.4 was
> > derived for next release.
> I believe it's just an iteration.  When we got 1.0.4 ready we renamed the
> trunk to 1.1.0-SNAPSHOT expecting that to be the next major release.  That
> doesn't mean there won't be anymore 1.0.x releases, but I think it means
> they will take place in the 1.0 branch.

That is correct.  To summarize the state of things:

* The website always shows the latest and greatest version of
  the website from the trunk (which is now targeted towards 1.1)

* Version 1.0.4 is in the process of being released.  One of the
  tasks along that way is a link (on the front page) to a static
  copy of the website as it was for that version.  This is not done
  yet but still needs to be.

* In the future, we're planning on two track development:

  - New features, in addition to bugfixes, go into the trunk
    targeting 1.1.x.

  - We have a branch for 1.0.x so we can do any needed
    emergency fixes to 1.0.4, without having to force the
    user to accept all of the new features on the trunk that
    might not be stable yet.

  - In general, you can assume that new features will *not*
    be backported from the trunk.  The whole idea is that we
    can turn around very quickly on bugfix or security vulnerability
    issues that might come up, with disrupting existing applications
    that are using the latest released version.

  - When a 1.1.x release achieves feature completeness, the
    cycle will start again ... the trunk will switch to 1.2 or perhaps
    2.0, and there will be a maintenance branch for 1.1.

We're setting this approach up deliberately to avoid some of the "long lead
time for a release" issues that have affected projects like Struts and
MyFaces, where it was difficult to do bugfixes quickly because everything
happened on the trunk (no branches).  We aim to do better than that.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message