[sakai2-tcc] Is there any reason I should not change the LTI version in trunk to 2.10-SNAPSHOT ??

[Matthew Jones]

Sending email on a weekend usually means it will get missed (or at least a
delayed response). I'll usually draft my weekend emails and send on Monday.
;)

And yea, it was discussed at the conference and there was some notes here. (
*Project organization and release process simplification)*
https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes
.

I read your email, Steve but haven't had time to respond to individual
points. I believe I agreed 100% on the outline of the current
problem/situation but wasn't sure about the solution. Really though any
solution is okay with me and I agree the current process isn't feasible for
the future. It's move of a question is who's going to put in the
(supposedly volunteer) time to do it? Anthony said he'd look at it and I'd
help him, but I'm pretty much booked with local work through the summer, so
likely wouldn't be doing anything extensive until late September/October. I
think this would be too disruptive for 2.9 but the proof of concept could
be done in trunk.

As far as the 2.10 LTI question, you're free to set whatever version you
want, but I think it would go to Steve's point and that doing this would
mean that you wouldn't have LTI released tied to the releases of 2.10 (when
that starts getting released) so possibly a slower process than currently.
And LTI has a separate project in JIRA which would need to be dealt with
separately.

There are really 2 types of indies. Indies that *are* indies because they
some other indie needed the api's (or some other dependency) from it in
order to build. You can't release the indie without having released it's
dependencies. Most of the indies are this type and these *could* be
collapsed easier because the version matches up better and they're still in
SAK. However this would require everything including any former indies that
had dependencies on these to be monolithic UNLESS the dependencies we're
independently released (can't be done easily with maven any way I know of)
or move them all to a separate project like edu-services is, something like
sakai-apis.

The indies that changed their version and have their separate JIRA project
are harder, because if they're merged back into CLE, it will make it harder
to track and report bugs against the old versions. If they remain outside
of the CLE it will still make it hard to know that these exist as separate
projects.

Then we have the problem of msgcntr which is version 3.x already. To get
around that, we either have to change the maven artifactId or groupId for
msgcntr or we'd have to go with all of Sakai beyond 3.x (this was part of
the 4.x proposal). So it might have to be 4.0 instead of 2.10 just because
of msgcntr.

Unless you were really looking for something to do, I don't think I'd jump
it with LTI yet. I'm hoping those interested will have a chance to talk
about this more in the near future, ideally finding a time with Steve if he
is going to be doing some of that work. I agree with the goal, I just need
a better roadmap for getting there.



On Mon, Jun 17, 2013 at 1:05 PM, Beth Kirschner <bkirschn at umich.edu> wrote:

> Steve -- at the conference we had discussed abandoning the indie approach
> to most, if not all tools, in the next major release -- currently to be
> called 2.10 (or 4.0?).
>
> Chuck -- I like the idea of changing the next version of LTI to 2.10.
> +1
>
> - Beth
>
> On Jun 16, 2013, at 6:45 AM, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:
>
> > Well if it stays an indie then it becomes super confusing since the
> version will at some point probably not line up with the reast of the
> actual 2.10 projects. I discussed this in my proposal, ie purepoms at 2.8.9
> or something when the Sakai release is 2.8.2 and other apps at 2.8.6. Head
> explosion.
> >
> > So it depends if you want to have off cycle release. If not and it is
> all to be rolled into the main release cycle then go for it.
> >
> > Was there any discussion on my proposal at the conference?
> >
> > cheers,
> > Steve
> >
> >
> > On Sun, Jun 16, 2013 at 2:26 AM, Charles Severance <csev at umich.edu>
> wrote:
> > I figure no time like the present...
> >
> > Of course I would need to fix target versions in JIRA - but that would
> be easy enough - there are only a few - so I could fix those by hand once I
> got a 2.10 tentative version.
> >
> > Thoughts / comments??
> >
> > /Chuck
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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/20130617/bbb0f6e9/attachment.html