[sakai2-tcc] 2.9.1-all tag available

Fri Feb 15 13:49:53 PST 2013

The built Apis for all tools are already released to the repository as part of the release process. So that takes care of the first and third point. 

The other one is Jenkins but that probably not as huge an issue as you think, as you can have tools built their dependent projects, so yeah it will build extra but not all. 

I am starting to see less value in the indies as well, especially now that tool development  has slowed right down. I don't think we should do anything to remove the indie nature( ie their assembly etc) just yet, but moving back to full source checkouts is probably what we need to do in the short term.

I disagree that the all tag isn't useful, a lot of people want to use it. And they probably base custom builds from it, so it's more of a convenience than anything. 

I do take copies of tags into msub and modify them with the same version number so that I don't have to adjust other projects, and there is nothing wrong with that. 

Cheers
Steve

Gesendent von meinem iPhone

On 16/02/2013, at 5:21, Matthew Jones <matthew at longsight.com> wrote:

> 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/20130216/409da143/attachment.html 