[sakai2-tcc] 2.9.1-all tag available

[Matthew Jones]

Thanks for bringing this up Chuck,

After releasing 2.9 11 times since b03, I've been increasingly unhappy with
it. Though I'm not sure if serious disruptions are better for a minor
release (2.9.2) or waiting until the next big one (2.10, or possibly 3.0
[or 4.0 if we say 3.0 was an unfinished experiment]) It's not super
difficult anymore, but there's a lot that can go wrong, and the things that
can go wrong may not be obvious for weeks or months later, causing a lot of
lost developer time, something we have limited amounts of. I believe that
the bundling up the released indies into this release adds no value to
developers, deployers, basically anybody. I can't see any audience that
really gains from this knowing what they're getting besides maybe upper
management who think that static compiling from tagged releases on static
numbers provide some kind of assurance over failures? Anytime you compile
something with maven the artifacts will be new, different and
unpredictable.

The static numbered tags are meant to not be changed, yet people will
download this 2.9.1-all, add local patches and re-compile and use their own
versions. (Often without changing the versions) This is what the SNAPSHOT
is for, active development and modification. The maven versions plugin
helps with a lot of this as well with the *versions:lock-snapshots *and
other pseudo-release goals.

Here's the value I see out of the *indies*
- The API's from all of the indies are useful to have released in the
repository.
  - Released API's mean that Jenkins can build an indie as soon as it's
modified and notify individual committers as soon as something breaks.
Otherwise it would have to build everything (which can take up to an hour)
and not often know what change broke the build.
  - Released API's also mean that contrib projects that use Sakai services
can build without having to build the entire core. You can just download
the contrib projects and mvn install sakai:deploy. This is pretty great.

- There is little value from the assemblies and core-deploy
  - You can't use a new assembly in an older version (For example a 2.9
assembly in 2.8). This was tried recently with Sitestats and because
FormattedText changed in kernel-util in 2.9 it failed when deployed into a
2.8 instance. So you'd have to recompile a new sitestats for 2.8 and for
2.9 if you want the newer sitestats, not just use the deploy (Or just
provide a sitestats bound against an old version of Sakai, which might also
work)
  - To actually use core-deploy and deploy something you need maven and
often java anyway, so you don't save anything other than downloading the
source. Often the source can be smaller than the binary anyway, not really
saving much on bandwidth costs
  - This increases the time for the buildled these are bundled up, even if
they're really not even used.

So here's what I think could happen or 2.9.2, but it would require some
work.

- Figure out a way to just release all of the API's. Either as a profile
hack in maven or as a file system hack with symlinks. (Haven't figured this
out yet)
  - This isn't even a huge deal if API's don't change after 2.9.1, since
all of the 2.9.1 one's are already released.
- Get rid of core-deploy (is not in the -all build anyway) and also get rid
of the assemblies (because they're not needed)
- Don't release anything independent, release everything together as a
monolithic release (Skip the release plugin)
  - To do this properly, master (which references api dependencies) would
need to point to the 2.9.1 versions of the apis, and all of the indies
would have to have their versions updated to *something*. Perhaps the
versions plugin could lock down these versions. What it's called doesn't
seem relevant as this version is mostly for QA purposes anyway and we can
just map it internally (for instance it would probably be something like
2.9-20131117.213112-16). Maybe the maven versions plugin could still be
used to update and not commit as well.

This is all what people seem to want anyway?



On Fri, Feb 15, 2013 at 8:28 AM, Charles Severance <csev at umich.edu> wrote:

> Thanks from all of us :)
>
> Hey (this is to everyone) - is there *any* reason not to make the 2.9.2
> tag - just the "all" variant and then also make a "2.9.2-partia" if folks
> really want a subset of the code when they check out?
>
> We might as well gently trend in that direction IMHO.
>
> Just thinking out loud - feel free to disagree.
>
> /Chuck
>
> On Feb 15, 2013, at 8:24 AM, Steve Swinsburg wrote:
>
> > Hi all,
> >
> > As discussed, I've created a 2.9.1-all tag:
> > https://source.sakaiproject.org/svn/sakai/tags/sakai-2.9.1-all/
> >
> > Work tracked here for future reference:
> > https://jira.sakaiproject.org/browse/SAK-23234
> >
> > I'll ping the dev list in a sec to respond to the other thread.
> >
> > cheers,
> > Steve
> >
> > _______________________________________________
> > 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/20130215/1167fd99/attachment-0001.html