[Building Sakai] Snapshot repo cleanup

[Bryan Holladay]

In this specific case, it was a branch from Dashboard 1.0.x which was
relying on this snapshot but has since been cleaned up and moved from
sakai-standard-tool to master.

-Bryan

On Wed, Oct 10, 2012 at 11:26 AM, Matthew Jones <matthew at longsight.com> wrote:
> Hi Seth,
>
> I was saying to Bryan locally that that Snapshot was deployed 2 years ago.
> https://source.sakaiproject.org/viewsvn/pure-poms/branches/purepoms-2.8.x/sakai-standard-tool/pom.xml?revision=82587&view=markup
>
> Since then in every revision the pattern appears to have been
> 2.8.#-SNAPSHOT, where # is some minor version number like 2.8.7-SNAPSHOT
> (https://source.sakaiproject.org/svn/pure-poms/branches/purepoms-2.8.x/pom.xml)
>
> If you were actually relying on this artifact out of the repository, your
> indies were probably getting a really old kernel-util added to them. (And
> possibly other older dependencies) and probably because of changes in the
> kernel (like the ehcache one) might not have worked anymore.
>
> It probably would have been best to just branch/build that specific version
> pure-poms locally if you still depended on that version existing with the
> correct information in it.
>
> Though I think this gets into the bigger discussion of the confusion around
> version numbers, especially 3 digit snapshots.
>
> Currently in 2.9 everything is on a 2 digit snapshot (2.9-SNAPSHOT etc)
> EXCEPT for content-review which is on a 3 digit snapshot (2.9.2-SNAPSHOT)
> for some reason. I've just left it and worked around it. There seems to be
> no "convention", according to this post [1] 10% of sampled artifacts use 3
> digit, the other 90% use 2 digit (or even 1 digit). There are advantages of
> a 3 digit though, for the person doing the release (me generally) it makes
> it very clear what the next release will be. However it can make it
> difficult when some modules aren't updated (in Seth's case)
>
> The ideal solution is that we get our api's (which shouldn't change in a
> release, and force a new release if they do change) to a 2 digit, and our
> impls and tools (which always change) to a 3 digit. That will take some time
> but has been something I've wanted for at least a year.
>
> I think for a moving released target, pure-poms 2.8.7-SNAPSHOT is correct
> though, and I think we'll also have the same pattern with master and kernel
> once we pass through RC to 2.9.0 and release 2.9.1-SNAPSHOT and
> 1.3.1-SNAPSHOT respectively.
>
> [1]
> http://forum.liquibase.org/topic/change-maven-version-snapshot-naming-convention
>
>
> On Wed, Oct 10, 2012 at 11:02 AM, Seth Theriault <slt at columbia.edu> wrote:
>>
>> On Tue, Oct 9, 2012 at 3:04 AM, David Horwitz <david.horwitz at uct.ac.za>
>> wrote:
>>
>> > As a result we where getting some problems with build pulling in these
>> > artefacts. As a result we have cleaned up this folder. Jenkins is busy
>> > rebuilding a whole bunch of 2.8.x and contrib projects that should
>> > repopulate the repo with current projects. If you build depends on an
>> > artefact thats no longer there please let me know.
>>
>> This cleanup broke our local build with some modules that have a
>> dependency on the 2.8-SNAPSHOT versions of purepoms stuff.
>>
>> We might be able to work around this (i.e., clean up our own stuff).
>>
>> Seth
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"