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

classic Classic list List threaded Threaded
17 messages Options
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

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

[ TCC/ PMC and CLE release team]

Hi, 

So with the removal of indies and project versions, I presume that Jira needs to be updated next to reflect the merged state of the Indies and to set the next version number of the release (for tracking purposes). Can we wait till just before we release the next major version of Sakai (currently called 2.10 or Trunk) or should we do it soon, so that we don't have to do double the work in configuring Jira and so we can get word out to the community and start explaining the rationale of the name, and a rough idea of plans-to-come?

Just asking.

Thanks,
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 13, 2013, at 9:53 AM, Steve Swinsburg <[hidden email]> wrote:

This has been the case for some time, trunk has been the same as trunk all, but it will be good to finally simplify this.

Cheers,
S

Sent from my iPad

On 13/09/2013, at 21:58, Neal Caidin <[hidden email]> wrote:

YES!

The team wants to get rid of TRUNK-ALL because it is redundant.

Cheers,
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 13, 2013, at 7:52 AM, Mark Breuker <[hidden email]> wrote:

Hi Aaron,

Does this mean that the main code line can now be checked out from TRUNK again instead of TRUNK-ALL?

Cheers,

Mark
Mark Breuker
Product Owner
Tel.: +31 71 5451 203
Leidse Onderwijsinstellingen bv
Leidsedreef 2
2352 BA Leiderdorp
www.loi.nl________________________________________
Van: [hidden email] [[hidden email]] namens Aaron Zeckoski [[hidden email]]
Verzonden: donderdag 12 september 2013 21:45
Aan: Sakai-Dev Developers; [hidden email]
Onderwerp: [Building Sakai] Removal of indies and project versions

This is a "heads up" (warning) for all developers and contrib tool authors.

With the completion of https://jira.sakaiproject.org/browse/SAK-23907
we will have removed all indies (projects which were versioned
separately from the main Sakai version and downloaded as a binary
instead of built during regular builds) and all indie project versions
(e.g. sakai.jsf.version) from the corporate POM (a.k.a. master). This
change includes the kernel. This has been committed to trunk as of
today and should be working for all core projects.

Any contrib tools which referenced older versions manually (e.g.
1.4.0-SNAPSHOT for kernel) or used the project versions will fail to
build against trunk after today. All non-core code should use the
Sakai master pom as parent and should not reference versions directly
but should instead exclude the version for all Sakai dependencies and
all maven dependency management to handle the versioning.

Look at the projects in the core for examples of the right way to do this.

Let me know if you have any questions.
-AZ


--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
cle-release-team mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

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

We could adjust the projects to have he one set of version numbers going forward, so they don't need to be adjusted individually for each release. One update and they all get the new version.

Though, are we planning on collapsing all jira projects into the one now? Since that will take care of all of this. Or will that be too intrusive? Note that all issue keys will be renamed…

cheers
S



On 17/09/2013, at 9:57 PM, Neal Caidin <[hidden email]> wrote:

[ TCC/ PMC and CLE release team]

Hi, 

So with the removal of indies and project versions, I presume that Jira needs to be updated next to reflect the merged state of the Indies and to set the next version number of the release (for tracking purposes). Can we wait till just before we release the next major version of Sakai (currently called 2.10 or Trunk) or should we do it soon, so that we don't have to do double the work in configuring Jira and so we can get word out to the community and start explaining the rationale of the name, and a rough idea of plans-to-come?

Just asking.

Thanks,
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 13, 2013, at 9:53 AM, Steve Swinsburg <[hidden email]> wrote:

This has been the case for some time, trunk has been the same as trunk all, but it will be good to finally simplify this.

Cheers,
S

Sent from my iPad

On 13/09/2013, at 21:58, Neal Caidin <[hidden email]> wrote:

YES!

The team wants to get rid of TRUNK-ALL because it is redundant.

Cheers,
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 13, 2013, at 7:52 AM, Mark Breuker <[hidden email]> wrote:

Hi Aaron,

Does this mean that the main code line can now be checked out from TRUNK again instead of TRUNK-ALL?

Cheers,

Mark
Mark Breuker
Product Owner
Tel.: +31 71 5451 203
Leidse Onderwijsinstellingen bv
Leidsedreef 2
2352 BA Leiderdorp
www.loi.nl________________________________________
Van: [hidden email] [[hidden email]] namens Aaron Zeckoski [[hidden email]]
Verzonden: donderdag 12 september 2013 21:45
Aan: Sakai-Dev Developers; [hidden email]
Onderwerp: [Building Sakai] Removal of indies and project versions

This is a "heads up" (warning) for all developers and contrib tool authors.

With the completion of https://jira.sakaiproject.org/browse/SAK-23907
we will have removed all indies (projects which were versioned
separately from the main Sakai version and downloaded as a binary
instead of built during regular builds) and all indie project versions
(e.g. sakai.jsf.version) from the corporate POM (a.k.a. master). This
change includes the kernel. This has been committed to trunk as of
today and should be working for all core projects.

Any contrib tools which referenced older versions manually (e.g.
1.4.0-SNAPSHOT for kernel) or used the project versions will fail to
build against trunk after today. All non-core code should use the
Sakai master pom as parent and should not reference versions directly
but should instead exclude the version for all Sakai dependencies and
all maven dependency management to handle the versioning.

Look at the projects in the core for examples of the right way to do this.

Let me know if you have any questions.
-AZ


--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
cle-release-team mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Aaron Zeckoski-3 Aaron Zeckoski-3
Reply | Threaded
Open this post in threaded view
|

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

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


On Tue, Sep 17, 2013 at 8:08 AM, Steve Swinsburg
<[hidden email]> wrote:

> We could adjust the projects to have he one set of version numbers going
> forward, so they don't need to be adjusted individually for each release.
> One update and they all get the new version.
>
> Though, are we planning on collapsing all jira projects into the one now?
> Since that will take care of all of this. Or will that be too intrusive?
> Note that all issue keys will be renamed…
>
> cheers
> S
>
>
>
> On 17/09/2013, at 9:57 PM, Neal Caidin <[hidden email]> wrote:
>
> [ TCC/ PMC and CLE release team]
>
> Hi,
>
> So with the removal of indies and project versions, I presume that Jira
> needs to be updated next to reflect the merged state of the Indies and to
> set the next version number of the release (for tracking purposes). Can we
> wait till just before we release the next major version of Sakai (currently
> called 2.10 or Trunk) or should we do it soon, so that we don't have to do
> double the work in configuring Jira and so we can get word out to the
> community and start explaining the rationale of the name, and a rough idea
> of plans-to-come?
>
> Just asking.
>
> Thanks,
> Neal
>
>
>
> Neal Caidin
> Sakai CLE Community Coordinator
> [hidden email]
> Skype: nealkdin
> Twitter: ncaidin
>
>
>
>
>
>
>
>
>
> On Sep 13, 2013, at 9:53 AM, Steve Swinsburg <[hidden email]>
> wrote:
>
> This has been the case for some time, trunk has been the same as trunk all,
> but it will be good to finally simplify this.
>
> Cheers,
> S
>
> Sent from my iPad
>
> On 13/09/2013, at 21:58, Neal Caidin <[hidden email]> wrote:
>
> YES!
>
> The team wants to get rid of TRUNK-ALL because it is redundant.
>
> Cheers,
> Neal
>
>
>
> Neal Caidin
> Sakai CLE Community Coordinator
> [hidden email]
> Skype: nealkdin
> Twitter: ncaidin
>
>
>
>
>
>
>
>
>
> On Sep 13, 2013, at 7:52 AM, Mark Breuker <[hidden email]> wrote:
>
> Hi Aaron,
>
> Does this mean that the main code line can now be checked out from TRUNK
> again instead of TRUNK-ALL?
>
> Cheers,
>
> Mark
> Mark Breuker
> Product Owner
> Tel.: +31 71 5451 203
> Leidse Onderwijsinstellingen bv
> Leidsedreef 2
> 2352 BA Leiderdorp
> www.loi.nl________________________________________
> Van: [hidden email]
> [[hidden email]] namens Aaron Zeckoski
> [[hidden email]]
> Verzonden: donderdag 12 september 2013 21:45
> Aan: Sakai-Dev Developers; [hidden email]
> Onderwerp: [Building Sakai] Removal of indies and project versions
>
> This is a "heads up" (warning) for all developers and contrib tool authors.
>
> With the completion of https://jira.sakaiproject.org/browse/SAK-23907
> we will have removed all indies (projects which were versioned
> separately from the main Sakai version and downloaded as a binary
> instead of built during regular builds) and all indie project versions
> (e.g. sakai.jsf.version) from the corporate POM (a.k.a. master). This
> change includes the kernel. This has been committed to trunk as of
> today and should be working for all core projects.
>
> Any contrib tools which referenced older versions manually (e.g.
> 1.4.0-SNAPSHOT for kernel) or used the project versions will fail to
> build against trunk after today. All non-core code should use the
> Sakai master pom as parent and should not reference versions directly
> but should instead exclude the version for all Sakai dependencies and
> all maven dependency management to handle the versioning.
>
> Look at the projects in the core for examples of the right way to do this.
>
> Let me know if you have any questions.
> -AZ
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
>
> _______________________________________________
> cle-release-team mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

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

Jira should forward them if they are moved within Jira, but I like the idea of archiving off the old project and moving any open issues over.


On 17/09/2013, at 10:35 PM, Aaron Zeckoski <[hidden email]> 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
>
>
> On Tue, Sep 17, 2013 at 8:08 AM, Steve Swinsburg
> <[hidden email]> wrote:
>> We could adjust the projects to have he one set of version numbers going
>> forward, so they don't need to be adjusted individually for each release.
>> One update and they all get the new version.
>>
>> Though, are we planning on collapsing all jira projects into the one now?
>> Since that will take care of all of this. Or will that be too intrusive?
>> Note that all issue keys will be renamed…
>>
>> cheers
>> S
>>
>>
>>
>> On 17/09/2013, at 9:57 PM, Neal Caidin <[hidden email]> wrote:
>>
>> [ TCC/ PMC and CLE release team]
>>
>> Hi,
>>
>> So with the removal of indies and project versions, I presume that Jira
>> needs to be updated next to reflect the merged state of the Indies and to
>> set the next version number of the release (for tracking purposes). Can we
>> wait till just before we release the next major version of Sakai (currently
>> called 2.10 or Trunk) or should we do it soon, so that we don't have to do
>> double the work in configuring Jira and so we can get word out to the
>> community and start explaining the rationale of the name, and a rough idea
>> of plans-to-come?
>>
>> Just asking.
>>
>> Thanks,
>> Neal
>>
>>
>>
>> Neal Caidin
>> Sakai CLE Community Coordinator
>> [hidden email]
>> Skype: nealkdin
>> Twitter: ncaidin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sep 13, 2013, at 9:53 AM, Steve Swinsburg <[hidden email]>
>> wrote:
>>
>> This has been the case for some time, trunk has been the same as trunk all,
>> but it will be good to finally simplify this.
>>
>> Cheers,
>> S
>>
>> Sent from my iPad
>>
>> On 13/09/2013, at 21:58, Neal Caidin <[hidden email]> wrote:
>>
>> YES!
>>
>> The team wants to get rid of TRUNK-ALL because it is redundant.
>>
>> Cheers,
>> Neal
>>
>>
>>
>> Neal Caidin
>> Sakai CLE Community Coordinator
>> [hidden email]
>> Skype: nealkdin
>> Twitter: ncaidin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sep 13, 2013, at 7:52 AM, Mark Breuker <[hidden email]> wrote:
>>
>> Hi Aaron,
>>
>> Does this mean that the main code line can now be checked out from TRUNK
>> again instead of TRUNK-ALL?
>>
>> Cheers,
>>
>> Mark
>> Mark Breuker
>> Product Owner
>> Tel.: +31 71 5451 203
>> Leidse Onderwijsinstellingen bv
>> Leidsedreef 2
>> 2352 BA Leiderdorp
>> www.loi.nl________________________________________
>> Van: [hidden email]
>> [[hidden email]] namens Aaron Zeckoski
>> [[hidden email]]
>> Verzonden: donderdag 12 september 2013 21:45
>> Aan: Sakai-Dev Developers; [hidden email]
>> Onderwerp: [Building Sakai] Removal of indies and project versions
>>
>> This is a "heads up" (warning) for all developers and contrib tool authors.
>>
>> With the completion of https://jira.sakaiproject.org/browse/SAK-23907
>> we will have removed all indies (projects which were versioned
>> separately from the main Sakai version and downloaded as a binary
>> instead of built during regular builds) and all indie project versions
>> (e.g. sakai.jsf.version) from the corporate POM (a.k.a. master). This
>> change includes the kernel. This has been committed to trunk as of
>> today and should be working for all core projects.
>>
>> Any contrib tools which referenced older versions manually (e.g.
>> 1.4.0-SNAPSHOT for kernel) or used the project versions will fail to
>> build against trunk after today. All non-core code should use the
>> Sakai master pom as parent and should not reference versions directly
>> but should instead exclude the version for all Sakai dependencies and
>> all maven dependency management to handle the versioning.
>>
>> Look at the projects in the core for examples of the right way to do this.
>>
>> Let me know if you have any questions.
>> -AZ
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email]
>> with a subject of "unsubscribe"
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email]
>> with a subject of "unsubscribe"
>>
>>
>> _______________________________________________
>> cle-release-team mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>>
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Aaron Zeckoski-3
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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

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 | [hidden email] | 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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

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

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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Bryan Holladay Bryan Holladay
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

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

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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 9:41 AM, Bryan Holladay <[hidden email]> 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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc




_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Bryan Holladay
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 | [hidden email] | 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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc




_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Neal Caidin-3
The msgcntr project already has a 3.1.0 (not 3.10) version specified in Jira to track trunk issues against. 

anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


On Sep 17, 2013, at 9:27 AM, Neal Caidin 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc




_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Bryan Holladay Bryan Holladay
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc





_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

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 | [hidden email] | 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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc






_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

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

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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 10:50 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc







_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

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 | [hidden email] | 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 10:50 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc








_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

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

I would defer to your (and others') judgment. Just trying to wrap my brain around it.

Thanks. 




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 11:03 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 10:50 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc









_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
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 <[hidden email]> 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 | [hidden email] | 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 10:50 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 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 <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
Skype: nealkdin
Twitter: ncaidin









On Sep 17, 2013, at 8:47 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | <a href="tel:517-980-0228" value="+15179800228" target="_blank">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 <[hidden email]> 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
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc







_______________________________________________
cle-release-team mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc