[cle-release-team] Versioning JIRA components

Tue Mar 19 12:11:49 PDT 2013

I am in total agreement with respect to 2.9 and beyond. I haven't formed an opinion about 2.8 other than that a proposal should be based on a success in the 2.9 sphere. Really only a matter of smaller bites and fewer variables at a time.

+1 to a flattening experiment alongside 2.9.x.

Thanks,
-Noah

On Mar 19, 2013, at 2:25 PM, Anthony Whyte wrote:

> Sorry for the delay in replying.  I got waylaid by an important meeting.
> 
> I need to test whether or not we actually disagree here.  First, I don't think proposals of this sort should be framed and voted upon without work that demonstrates both the upside and downside of the change envisioned.  So voting before doing some branch work as well as assessing the impact of change on local deployers I consider a part of framing the proposal.  
> 
> Second, we should avoid doing anything that creates a disincentive for schools to upgrade to 2.9 in 2013.  It's in no one's interest to have schools holding back in hopes of the next big thing.  While it's fun to imagine organizing ourselves in a way to produce an upgrade path with "lots of upside . . . and few distractions" I think an incremental approach more realistic given current realities.  Besides, talking in terms of "lots of upside" is itself conducive to the kind of "freeze" we want to avoid with respect to 2.9 adoption.  
> 
> I'd like to target both 2.9 and 2.8 in addition to trunk because I think the risk of disruption to the maintenance branches low and because targeting trunk imposes what I regard as an unnecessary delay in introducing an incremental improvement to our release process as well as simplifying issue tracking across trunk, 2.9 and 2.8 for a set of modules that, in the main, all maintained by the same small set of developers.        
> 
> Having reviewed the recent release history of the modules discussed in this thread, the suggestion that we consider re-versioning trunk, 2.9 and even 2.8 as a first step towards simplifying both our builds and the tracking of issues I don't regard as all that revolutionary.  Take the kernel.  It's not seen an off-cycle release since October 2011 and if we continue to tighten our release cycles we can probably avoid an off-cycle kernel release in future (emergencies excepted).  Rev'ing kernel-1.3.3-SNAPSHOT to 2.9-SNAPSHOT or kernel-1.2.10-SNAPSHOT TO 2.8-SNAPSHOT at a well advertised point in the future I doubt will prove all that disruptive.  The same goes for the other modules.  We should of course check with deployers if handing them a new 2.9 or 2.8 OOTB .externals file to work from will prove troublesome.  Steve thinks it may for 2.8, I think otherwise.  
> 
>> If we can frame changes to 2.9 as a gentle preparation for this longer range planning, I think that is a winning scenario. 
> 
> 
> Exactly.  Again, I regard this as an incremental change, despite it's implications for the indie release process.  It will involve some changes to institutional build patterns but I think for the better.    
> 
>> The scenario we definitely want to avoid is making some well-intended but very unique and challenging maintenance release that changes institutional build patterns dramatically, well off of their usual cycle. 
> 
> 
> I think we can avoid this.
> 
> / Anth
> 
> 
> 
> 
> On Mar 19, 2013, at 11:09 AM, Noah Botimer wrote:
> 
>> This is an answer to a slightly bigger question...
>> 
>> Despite my rambunctious responses, I do note that we need to be deliberate here. We have to keep in mind that many adopters have had pretty confusing messaging about the CLE and surrounding projects / groups for the past couple of years. We need 2.9 to be a safe, predictable place.
>> 
>> I am in full support of these goals and am working toward them, but the last thing I want to do is to add extra uncertainty to 2.9. If we are to make progress, we need the majority to adopt it and then make the next upgrade an obvious one, with lots of upside (easier to install, faster, safer, easier to maintain) and few distractions (no new portal in 2.10, no major user retraining for tools).
>> 
>> Part of the predictability equation for 2.9 is to not freeze everybody in a wait for 2.10 (look back to what 2.9 did to 2.8 adoption). I think the message needs to be roughly that 2.10 will have some important improvements but they will be extensions of 2.9, not some revolutionary thing that's going to hurt, so everyone should get to the newest 2.9 release as soon as they can.
>> 
>> If we can frame changes to 2.9 as a gentle preparation for this longer range planning, I think that is a winning scenario. The scenario we definitely want to avoid is making some well-intended but very unique and challenging maintenance release that changes institutional build patterns dramatically, well off of their usual cycle. This would be to hold fixes hostage to our refactoring and be a self-defeating double-move.
>> 
>> 
>> So, to go to the next step question...
>> 
>> As far as reversioning, it may not be too disruptive, but it will be confusing. There's no reason we can't experiment off the branch and see what we think. There's enough expertise on this list to test the hypothesis before doing prospective changes in 2.9.x, which I think would be a mistake. I think that's step one -- define and vet our plan.
>> 
>> The next step would be writing the explanation text (aimed directly at adopters, specifically builders). This should absolutely be done and distributed before 2.9.x changed shape.
>> 
>> As far as any repackaging ideas, these to me seem outside of the 2.9 line -- which I don't think is in conflict with any proposed ideas so far. But we do want to make sure that the goals are aligned (reversioning and repackaging are just tools to get somewhere; so we need to make those connections explicit).
>> 
>> In sum -- I love it. Let's rock.
>> 
>> Thanks,
>> -Noah
>> 
>> On Mar 19, 2013, at 9:56 AM, Sam Ottenhoff wrote:
>> 
>>> 
>>> 
>>> I say all this with a caveat: If we drop the indies and their potentially rapid release cycles, we need to have more rapid full Sakai maintenance releases (and if the process is simpler and quicker than it is now, I will do them). We cant wait months between releases
>>> 
>>> Agree with you and Anthony here.  I think we need to release near as fast as the fastest indies released.  This means 4-6 maintenance releases per major release instead of 2-3.
>>> 
>>> So the main goals would be: easier releases (less release tasks => more releases) and easier JIRA work (centrality of issues => easier maintenance).
>>> 
>>> What's the next step here?  Do I need to ask the TCC for a vote?
>>> 
>>> --Sam
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> 
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130319/8a7768ad/attachment-0006.html 