[cle-release-team] Versioning JIRA components

Tue Mar 19 12:01:28 PDT 2013

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/64e5f64f/attachment-0006.html 