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

[Neal Caidin]

I'll check with Anthony and Seth (Chair/ Vice Chair) on best way to proceed. I don't think we have come to consensus on naming it Sakai 4 and part of my question is whether it would be better to make the decision now vs waiting. 

Pros of making decision on name right now
-------------------------------------------------------------
Setup Jira the way we need to rather than having to convert (though it sounds like converting will be relatively little effort)

Start the discussion in the broader community about the rationale for the name, and expectation setting

Cons of making decision right now
----------------------------------------------------
If getting hung up on a name impacts our collective work on Sakai 2.10 in a negative way, that would be a bad thing.

That's all I've got for now.

Thanks,
Neal



Neal Caidin
Sakai CLE Community Coordinator
neal.caidin at apereo.org
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 9:41 AM, Bryan Holladay <holladay at longsight.com> 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130917/ca963687/attachment-0001.html