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:13:22 GMT
> We will also need to do more work in JIRA to track an issue that will
> be fixed in multiple branches, as well as issues that apply to
> multiple branches.

I think that the work is already there -- we get to choose what
release(s) a bug applies to, and what release(s) it was fixed in.

We will need to decide (probably on a case-by-case basis) what issues
to backport from "old" branches, but that's a separate issue, and one
that JIRA won't be much of a help with. For example, if we have a 1.0
branch and a 1.1 branch and are working on 1.2 in the mainline, and we
decide to make a 1.0.8 release, we'll need to decide whether to move
those fixes to 1.1 or just to the mainline.

-Patrick

On 7/9/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> Hi Patrick,
>
> I like the proposal. Once we all agree on this strategy, can you
> update the wiki on release policy to match our plans?
>
> We will also need to do more work in JIRA to track an issue that will
> be fixed in multiple branches, as well as issues that apply to
> multiple branches.
>
> Craig
>
> On Jul 9, 2007, at 10:05 AM, Patrick Linskey wrote:
>
> >> 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.
> >
> > Agreed -- hence this thread, in fact.
> >
> > Additionally, I'd like to see a small addition to our process. I
> > alluded to this in my original message, but it's probably worth
> > calling out explicitly.
> >
> > I think that the model of essentially releasing directly from the
> > mainline worked well for our incubating / 0.9 releases. But I don't
> > think that this really scales that well for GA-style releases, since
> > there are often going to be various projects going on in the mainline
> > that might have different lifecycles.
> >
> > So, from a branching standpoint, I'd like to see us create a branch
> > off of the trunk when we start zeroing in on a release. Unlike
> > branches that we created earlier, these branches are not just for the
> > purpose of assembling the release artifacts, but are also for work
> > happening to get to the point of being release-ready. Additionally,
> > they will live on in time as "the" branch for a particular release
> > number. So, under my proposal, we will create a 1.0 branch soon, and
> > ongoing work to resolve issues slated for 1.0 will happen in that
> > branch. Once 1.0.0 is cut, we will tag that branch, and the only work
> > that will happen in that branch will be bugfixes for 1.0.1. Once 1.0.1
> > is cut, we will again tag the branch, and repeat.
> >
> > In my experience, generally, it works well to branch like this for
> > every major.minor combination. I.e., we don't create separate branches
> > for version 1 and version 2; rather, we create a branch for 1.0, 1.1,
> > 1.2, 2.0, etc. once we get to that point on trunk.
> >
> > Thoughts?
> >
> > -Patrick
> >
> > On 7/9/07, Kevin Sutter <kwsutter@gmail.com> 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
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
> 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