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:05:42 GMT
> 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

Mime
View raw message