openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: 1.0 steps?
Date Mon, 09 Jul 2007 17:07:47 GMT
> to make a branch. Once the branch is cut, fixes would have to be made
> in both branch and trunk, so it's not a trivial decision.

Actually, modern VCS systems allow changes to be merged from a branch
back down to the mainline. In my experience, this is fairly
straightforward assuming that the merges happen in a timely fashion,
so I think that this is a fairly trivial decision.

In my experience, it's much better in general to make changes in one
place and then do VCS operations to merge them back down to trunk.

That said, I do look forward to the day when svn supports
automatically keeping track of branching history.

-Patrick

On 7/9/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> I think we need to first go through the list of JIRA issues for 0.9.8
> and 1.0.0 and really think hard about whether they should be fixed or
> not.
>
> We also need a release manager (a person who will do what Marc and
> Mike did for 0.9.6 and 0.9.7).
>
> Maybe we should post the list of proposed deferred JIRA issues for
> discussion and then move them. I like the idea of defining both a
> 1.0.1 and 1.1.0 release target to which to defer issues.
>
> I think once there is consensus on the non-deferred issues and an
> identified JIRA owner for them, the release manager can propose when
> to make a branch. Once the branch is cut, fixes would have to be made
> in both branch and trunk, so it's not a trivial decision.
>
> Maybe a wiki with a table of JIRA issues and proposed target release
> and some justification (with author's name) would be useful. It's not
> too hard to set up but still might not be worth the effort.
>
> Craig
>
> On Jul 9, 2007, at 9:50 AM, Kevin Sutter wrote:
>
> >>
> >> What is remaining to get to a 1.0 release? Are there any things in
> >> particular that people think are important to work on? Maybe it's
> >> about time for us to create a branch for 1.0 finalization and
> >> hardening.
> >
> >
> > This probably depends on what our goal is for a 1.0 release.  If
> > it's just
> > to have a 1.0 release since we graduated to a TLP, then we're
> > probably close
> > to starting that process.  But, if we are looking for a certain
> > level and
> > hardness of function, then we still may have a fews things to clean
> > up.  I'm
> > okay with going for a 1.0 release just to have one, but I would
> > then like to
> > start working on defining the follow-on release (1.0.1 or 1.1).
> >
> > No matter what type of 1.0 release we decide to go for, maybe we
> > should
> > incorporate the voting mechanism within JIRA to help determine what
> > Issues
> > are important?  I am not totally familiar with this process, but it
> > allows
> > users to vote on the Issues that are most important to them.  Each
> > user is
> > allowed a certain number of votes (to keep them from voting for "all"
> > Issues).  We can use that as input to our selection criteria.
> >
> > But, before we open up for a vote, do we need some time to review
> > all of the
> > open Issues and assert 1.0 vs post-1.0?  Something along the lines
> > of what
> > Patrick did for the previous release?  I just find it kind of
> > difficult to
> > be working on various problems and then "ding", the timer goes off
> > and we've
> > cut off development for a given release.  It's probably time to start
> > working out a candidate release cycle and content.
> >
> > Kevin
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message