[cle-release-team] [sakai2-tcc] Sakai trunk name? - Re: [Building Sakai] Removal of indies and project versions

Steve Swinsburg steve.swinsburg at gmail.com
Tue Sep 17 13:54:45 PDT 2013 

I think it was more on an oversight than a precedent ;) It is totally confusing to have code versioned as one thing and jira versions as another. There are other projects that have this issue in the SAK project, and I keep raising issues with it to get the versions sorted out. 

So perhaps in this transition phase we could leave some Jira projects out on their own, but start to standardise the version numbering in Jira (i.e. adding 2.10 [Tentative] to these projects). Trunk poms should be reversioned to 2.10 SNAPSHOT.

Then as older versions drop off, we will be collecting standardised named tags and branches in SVN, and Jira will start to reflect the real state of affairs.

For simpler projects that only have a few versions and they map pretty well (i.e. Profile2 1.3 > Sakai 2.7, 1.4 > 2.8, 1.5 > 2.9, 1.6 > 2.10) then they could just have a simple bit of text describing the mapping put somewhere and be immediately reversioned in Jira. For example Profile2 could have this done right now. 

The only caveat is that there are a lot of intermediate fix versions that will not map to Sakai versions (i.e. there were like 19 releases of 1.3, 12 releases of 1.4) but the 1.5 releases have been about on par with the 2.9 releases. So whether or not we want to roll them into the one fix version or not is to be decided.

cheers,
S






On 18/09/2013, at 1:03 AM, Anthony Whyte <arwhyte at umich.edu> wrote:

> As noted earlier, a precedent was set when Steve re-worked webservices as an indie, re-versioned it 1.x, but continued to log issues in SAK.
> 
> One needs to decide where you want to contain possible confusion.  At the Jira level where people (some non-devs) log tickets against known general versions of Sakai or at the pom level where devs work (most with long experience in the project).  
> 
> Anth
> 
> 
> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
> 
> 
> On Sep 17, 2013, at 10:58 AM, Neal Caidin wrote:
> 
>> Would this cause any POM confusion?  By that I mean that the versions of MSGCNTR are in the POMs at the snapshot of the version when the release was tagged. Those numbers in Jira will not correspond to the Snapshot versions of the release.
>> 
>> ?
>> 
>> 
>> Neal Caidin
>> Sakai CLE Community Coordinator
>> neal.caidin at apereo.org
>> Skype: nealkdin
>> Twitter: ncaidin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Sep 17, 2013, at 10:50 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
>> 
>>> Looking at the msgcntr project versions, one could remap the versions between the msgcntr and SAK project as follows:
>>> 
>>> msgcntr -> SAK
>>> 3.1.0 --> 2.10
>>> 3.0.4 --> 2.9.4
>>> 3.0.3-> 2.9.2
>>> 3.0.2->2.9.2
>>> 3.0.1->2.9.1
>>> 3.0.0->2.9.0
>>> 2.8.4->2.8.3
>>> 2.8.3->2.8.2
>>> 2.8.1,2.8.2->2.8.1
>>> 2.8.0->2.8.0
>>> and so on, mapping each version against the CLE version for which it was intended.
>>> 
>>> Once you hit msgcntr 2.7.2 the version corresponds with the CLE version.
>>> 
>>> Note again.  This is Jira admin work.  No code is touched.
>>> 
>>> Once done, the msgcntr project could be whacked.
>>> 
>>> Anth
>>> 
>>> 
>>> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
>>> 
>>> 
>>> On Sep 17, 2013, at 10:41 AM, Bryan Holladay wrote:
>>> 
>>>> cool.. just was wondering.  I'd suggest keeping msgcntr in sync with the rest of the Sakai 2.10 tool jira's convention and it shouldn't be an independent project in Jira.
>>>> 
>>>> 
>>>> On Tue, Sep 17, 2013 at 10:36 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
>>>> Consensus as yet does not exist among TCC/PMC members regarding re-versioning trunk to 4.0.  In order to avoid holding up the work on eliminating trunk indies until version consensus is achieved, we standardized on 2.10, the default version at present.
>>>> 
>>>> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
>>>> 
>>>> 
>>>> On Sep 17, 2013, at 9:41 AM, Bryan Holladay wrote:
>>>> 
>>>>> Msgcntr should go back into the SAK jira project and keep on track with the rest of Sakai.  3.10 would be confusing, since it's neither Saka's version track nor Msgcntr's version track.  Also, why are we using 2.10 anyways?  I thought the consensus was 4.0?
>>>>> 
>>>>> 
>>>>> On Tue, Sep 17, 2013 at 9:27 AM, Neal Caidin <neal.caidin at apereo.org> wrote:
>>>>> Does it make sense for Msgcntr to have a 3.10 version available to track it's fixes for Sakai 2.10, for now?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Neal Caidin
>>>>> Sakai CLE Community Coordinator
>>>>> neal.caidin at apereo.org
>>>>> Skype: nealkdin
>>>>> Twitter: ncaidin
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sep 17, 2013, at 8:47 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
>>>>> 
>>>>>> Neal, to be clear, project versions have not not been removed.  Project versions in trunk for certain ex-Indie projects have been standardized on 2.10-SNAPSHOT.  Two exceptions to this effort include Msgcntr and Lessonbuilder, the former because it's versioned 3.0, the latter because we are awaiting a reply from Chuck Hedrick regarding the right moment to branch LB trunk to a 1.5.x branch before proceeding to eliminate LB's assembly module and update it's version to 2.10-SNAPSHOT in line with all other core modules, save Msgcntr.
>>>>>> 
>>>>>> All ex-indie Jira projects have been updated (trunk versions have been remapped as 2.10), Msgcntr and Lessonbuilder excepted.  What may not have been completed is providing new components for the ex-Indies in the Sakai CLE project and then moving all open 2.10-related tickets from the individual indie projects to the Sakai CLE project.  The goal would be consolidating Sakai trunk issue tracking under a single project .  The old indie projects (e.g., basiclti, polls, search, etc.) would need to remain for historical purposes unless we want to remap all the previous indie versions to the Sakai CLE project.   Although it could be done, it would constitute a tedious task.
>>>>>> 
>>>>>> Now, it might make sense to remap the more active Jira projects (e.g., BasicLTI) so that csev et al need only work out of a single Jira project rather than two.  I recall that the webservices project, although formerly versioned 1.x, remained a component of the 2.x versioned Sakai CLE project.  To be clear, this is a Jira task, no code would ever be touched.  I would only recommend consolidating Jira projects if people think confusion will arise in Jira where project are only partly amalgamated.
>>>>>> 
>>>>>> Currently, csev can log his trunk tickets in the BasicLTI project.  He can also log them in the Sakai CLE project.  He and others might find this confusing, although over time ticket traffic on the old Basiclti project would fade away as Sakai moves forward.
>>>>>> 
>>>>>> In an ideal world we'd all work out of a single Jira project.  Whether it makes sense to move towards the ideal (in an incremental fashion) is probably worth a (very short) discussion.
>>>>>> 
>>>>>> Currently the next trunk-based release of Sakai is 2.10.  That's good enough for the present.  If a decision is made to change the version to 4.0 it can be done quickly with very little fuss.
>>>>>> 
>>>>>> Anth
>>>>>> 
>>>>>> 
>>>>>> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
>>>>>> 
>>>>>> 
>>>>>> On Sep 17, 2013, at 8:44 AM, Charles Severance wrote:
>>>>>> 
>>>>>>> I would certainly volunteer LTI as guinea pig.   I don't need all the api, impl, util, etc detail - it could all collapse into one "LTI".
>>>>>>> 
>>>>>>> /Chuck
>>>>>>> 
>>>>>>> On Sep 17, 2013, at 8:35 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>>>> 
>>>>>>>> I think the plan is to begin to collapse projects together where it
>>>>>>>> makes sense. That will definitely be easier to maintain in the long
>>>>>>>> run.
>>>>>>>> I think some projects might stay separate (e.g. kernel) but I am not
>>>>>>>> sure about that. I would say we probably should just move open issues
>>>>>>>> over to SAK and then close the old projects and leave them as they are
>>>>>>>> (so that no one can create or modify the existing issues). This way
>>>>>>>> all the links don't break (or will JIRA be smart enough to forward the
>>>>>>>> old links?).
>>>>>>>> 
>>>>>>>> Maybe we just need to experiment on a smaller one first?
>>>>>>>> 
>>>>>>>> -AZ
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> _______________________________________________
> 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/20130918/f6a4c612/attachment-0001.html

More information about the cle-release-team mailing list