openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: 1.0 steps?
Date Mon, 09 Jul 2007 17:21:07 GMT

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!


Mime
View raw message