lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Male <gento...@gmail.com>
Subject Re: discussion about release frequency.
Date Fri, 10 Sep 2010 00:45:37 GMT
+1 to more frequent releases.  I think we are already seeing 3x being pushed
forward as the stable version for users wishing to do some development of
their own.

I am more than happy to work with whoever on the maven issues as I feel that
it is really important to keep making maven releases.  Maven does have a
release plugin, similar to what you want to build for ant, perhaps that can
provide some inspiration?

Chris

On Fri, Sep 10, 2010 at 12:06 PM, Mark Miller <markrmiller@gmail.com> wrote:

> +1 here too - I'm all for more frequent releases - not sure how much
> time I can put behind that release to release, but I'm all for the idea
> of it.
>
> - Mark
>
> On 9/9/10 5:54 PM, Michael McCandless wrote:
> > +1 to simplify the release process / ReleaseTodo wiki, and +1 to
> > release a 3.1, and +1 to do frequent stable releases.
> >
> > Having a stable branch gives us that freedom and we should use it!
> >
> > Mike
> >
> > On Thu, Sep 9, 2010 at 2:41 PM, Robert Muir <rcmuir@gmail.com> wrote:
> >> Hello,
> >>
> >> I would like to open a discussion about release frequency from
> lucene/solr's
> >> 3x branch. I'm not asking for votes or anything, just ideas.
> >>
> >> For Lucene/Solr its been a pretty long time since the users got a
> feature
> >> release.
> >> I don't consider Lucene 3.0 as a feature release either.
> >>
> >> I think now that we have a "trunk" for unstable development, and a "3x"
> >> stable branch, that we should think about cutting releases from this
> branch
> >> much more often, for example every month or two.
> >>
> >> I think that by doing this, we will engage the community more: because
> many
> >> people won't run svn checkouts/snapshots, and many people probably wont
> even
> >> look at unreleased code.
> >>
> >> In the past it seems releases were fairly infrequent, and I'm not sure I
> >> have the background to really understand why, but i have 3 theories:
> >> * concerns about the actual code being stable
> >> * the release process is too complicated
> >> * getting someone to do the work
> >>
> >> For stability, my argument is that our "3x" stable branch is inherently
> more
> >> stable than previous trunks were, so its safe to release more often from
> it.
> >> I give some very rough, very unscientific numbers below from Lucene's
> JIRA,
> >> but I think the same applies to Solr.
> >>
> >> Based on the last 4 weeks of development (resolved issues):
> >>
> >> Of bugfixes, about half (6) are fixes to bugs that already existed in
> >> 2.9/3.0
> >> About 25% (3) are fixes to bugs we only introduced in trunk, and do not
> >> affect 3x.
> >> The other 25% (4) are fixes to things we introduced in trunk/3x
> >>
> >> You could say this suggests 3x is very roughly "twice" as stable as
> trunk,
> >> yet has about 80% of the new features/improvements (14 out of 17).
> >>
> >> With regards to the release process: I also think if we decide to do
> this,
> >> we must simplify and automate our release procedures.
> >> To be frank, http://wiki.apache.org/lucene-java/ReleaseTodo scares the
> crap
> >> out of me, and something like 'ant release' that someone can run from
> the
> >> top level for both Lucene and Solr would really go a long way towards
> making
> >> the release process less painful. I realize this is difficult and cannot
> be
> >> fully automated but I think it can be improved.
> >>
> >> Finally, as far as getting someone to do the work, I can certainly
> volunteer
> >> to help in the following ways:
> >> * being RM if you are ok with a non-maven release (until LUCENE-2268 is
> >> fixed, i am uncomfortable with maven)
> >> * improving the build to simplify the release process: (see SOLR-2002
> for a
> >> start)
> >>
> >> --
> >> Robert Muir
> >> rcmuir@gmail.com
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
Chris Male | Software Developer | JTeam BV.| www.jteam.nl

Mime
View raw message