[cle-release-team] Versioning JIRA components

Tue Mar 19 14:45:51 PDT 2013

Sure. Let me be clear. I am in support of things that actually reduce net complexity and have been proven out. We are the workers and the first line of customers here, so I think we are in a good position to identify the issues and validate potential solutions. If that means 2.9, 2.8, just trunk, or no change, so be it.

My overall point last week was that our modularization is incomplete, has not proven efficient or simple, and does not need to persist. My opinion is that the modules should be condensed, and our version numbering simplified and disambiguated. The right time and place for that is pending input (like Matt gives here). If it's more pain to make retroactive changes, then we shouldn't -- not much risk of that if we test the hypothesis alongside a release line.

To go back to Sam's initial question, I don't think the JIRA feature of versions on components separately from a project is incoming any time soon, nor would it really be all that helpful in tracking which indie changes are headed for which core release. It's a red herring in the gap between our real and imagined complexity and resource level.

I still contend that flattening (and moving forward in version number to disambiguate) is our best strategy and leave it to those closest to the release execution, adoption, and customization to refine that base proposal.

Matt's concern here about API, kinda-but-not-really SPI, and implementation versioning is a different one. We could certainly make progress there, but I think there's more extensive repackaging to consider under that heading, which I won't get into now.

Thanks,
-Noah

On Mar 19, 2013, at 3:01 PM, Matthew Jones wrote:

> I'm with Steve, I wouldn't do this for 2.8 or even 2.9 at this point. I also would still leave kernel off on it's own as well for now. It would cause a large disruption to anyone running an existing instance since they'd have to essentially start completely fresh and clean. Also a few tools went far beyond 2.8.3 (like reset pass 2.8.7 and content-review 2.8.8) so you'd essentially be on like 2.8.10? 
> 
> In fact I'm going to come out and say I won't personally be involved in any re-versioning effort described for existing (2.9) and certainly not past releases (2.8). Longsight is "mostly happy" with how these releases are as-is and any disruption would cause us additional local work and community work that I don't see any strong value in doing either way. The biggest problem I have with the release currently is:
> 
> - The master snapshot versions change (get bumped up) on each release because the release plugin does a 3 digit snapshot. 
> 
> 
>         <sakai.announcement.version>2.9.2-SNAPSHOT</sakai.announcement.version>
> 
> That's really about it. So actually doing a release is a disruption over 2.8 where it was 2 digit (2.8-SNAPSHOT). The Longsight process is to update individual tools when the client has a problem or there's a security fix, but when api's change it means you have to also update the dependencies and deploy even more stuff. 
> 
> Having it 2.8-SNAPSHOT wasn't entirely correct though because there *were* people who did make changes into the api's in the minor releases. It also wasn't clear without looking somewhere else what the next version should be. In 2.8, in the branch it had static versions and this makes sense but it wouldn't work if someone actually modified an api locally for anything that had a parent of master. Since purepoms was used with local overrides this was less of an issue than for 2.9 where everything was folded into master. We should have had a 2 digit static versions across the board in here, just have it version 2.9 (for all releases) and 2.9-SNAPSHOT for the branch. This would be a huge improvement since we mostly deploy of 2.9.x.
> 
> I'd be happy folding this all back but I think having the api's for the release in the repository is useful for getting contrib tools up quicker. I think we need to be better about keeping our apis for internal and external (with direct/keitai) stable for an entire release. (SAK-21959) The more often these change the harder it is for these developers to keep up.
> 
> 
> 
> On Tue, Mar 19, 2013 at 2:25 PM, Anthony Whyte <arwhyte at umich.edu> 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
> 
> 
> _______________________________________________
> 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/fc712e5c/attachment-0006.html 