[cle-release-team] Version of next SNAPSHOT's after 2.9.0

Matthew Jones matthew at longsight.com
Fri Nov 9 14:17:21 PST 2012


Okay here's how it stands right now.

Sakai Core = 2.9-SNAPSHOT (Unchanged) - sakai.version in master is
2.9-SNAPSHOT
Master and Kernel = 2.9-SNAPSHOT and 1.3-SNAPSHOT respectively (Unchanged).
Also defined as properties

All indies defined in master are a 3 digit snapshot and use the properties
as defined in master.

I tried to fix the items in core but too many (non-indies) are incorrectly
defined in master. Some of these were cleaned up in SAK-22888, but I just
gave up and figure this is more of a future project at this point, as I
don't have the time for it right now.

I tested 2.9.x-all and it compiles fine. it should deploy tonight on
nightly.


On Fri, Nov 9, 2012 at 11:22 AM, Matthew Jones <matthew at longsight.com>wrote:

> Cris sent me a pretty good question for the next release SNAPSHOT's. I
> hadn't exactly noticed but the release process set all snapshots to 3
> digits. Only some indie snapshots were 3 digits prior to this occurring.
>
> So for instance, kernel went from
> 1.3-SNAPSHOT to 1.3.1-SNAPSHOT. It seems to me that this is the *correct*
> version as it indicates that this is a SNAPSHOT which is targeting the
> 1.3.1 release.
>
> However the problem with this is that with the sakai:deploy goal, it will
> end up deploying duplicate artifacts, 1.3-SNAPSHOT and 1.3.1-SNAPSHOT.
> Currently as we all know, there is no sakai:undeploy goal to clean up
> anything prior. (SMP-10)
>
> So this essentially means that with each new "release" a developer would
> need to start with a fresh tomcat if they were using 2.9.x. This wouldn't
> effect nightly as this is what it does.
>
> Typically our advice has been to clean your tomcat regularly to avoid
> problems like this, I'd just want some opinions I guess.
>
> We could *possibly* come up with a regex to convert these all back to 2
> digit SNAPSHOT's. However the big negative this would make it much harder
> for anyone other than myself to know what version to release since the it
> would want to release the next version (which would be 2.10). You have to
> manually override that with the correct version.
>
> This wouldn't break nightlies build process, or Longsights build process
> (we clean out tomcat before updates). So I'm leaning on sticking with this
> and either getting the undeploy working or some script to look for/clean up
> old artifacts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121109/9f5747ac/attachment-0006.html 


More information about the cle-release-team mailing list