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:28:21 GMT
> Except I thought that we would work on the most recent code line that
> showed the issue and decide later if the fix should be back-ported to
> earlier code bases.

Well, sometimes we'll probably do it that way, but sometimes one of
those pesky users will come along with a problem in an earlier
release, and in those situations my modus operandi has always been to
test and fix the problem against the release that they're using
(within lifecycle policy), and then worry about getting the fix into
the mainline "later".

In a world where we do periodic patch releases, pushing the changes
down to the trunk just becomes part of the process for doing the
patch.

> > That said, I do look forward to the day when svn supports
> > automatically keeping track of branching history.
>
> Not sure what more svn should do for us here...

It's my understanding that in svn, when merging from a branch down to
trunk, you need to tell it "merge changes from point foo to point bar
to the trunk", where bar is usually "now". In Perforce, for example,
you just say "merge changes from this branch to the trunk" and the
system keeps track of making sure that things previously merged don't
get re-merged. IOW, Perforce keeps track of the branch and merge
history, thus saving the poor brancher from doing same. I hear that
"they" are working on such functionality for svn 2.

-Patrick

On 7/9/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> On Jul 9, 2007, at 10:13 AM, Patrick Linskey wrote:
>
> >> 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.
>
> Heh, that's exactly the human involvement I'm referring to that we
> need to have with multiple active code lines...
>
> Except I thought that we would work on the most recent code line that
> showed the issue and decide later if the fix should be back-ported to
> earlier code bases.
>
> Craig
> >
> > -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
>
> 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