openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: 1.0 steps?
Date Mon, 09 Jul 2007 17:12:01 GMT


> 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.

I agree that this would be a good idea.




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


Mime
View raw message