[Building Sakai] 2.9: How to cut a custom release

[Matthew Jones]

I'd thought that we'd tested local DM to override inherited DM. However if
it's the case as you say the only two options I can think of are

* Declare the actual <version> right in every the <dependency> block in the
local tool. This for sure should override dependency management.
* Rather than having a parent of master, perhaps just having a
dependencymanagement import scope on master (or a subset of master) could
work out better? The parent would be either something simpler (like a
single pom defining some just some essential sakai plugins and repositories)
 - I feel like this is what the pure-pom real intention and what we wanted
to accomplish for 2.9, but just couldn't figure it out at the time?
 - The problem with pure-poms is that they still defined version
information and needed to be released, often as often as master. Many
people doing local builds would forget (or not know) to modify the versions
in the pure-poms when changing the kernel, or edu-services Version
information (suggestions) should only be in one place (for scope import)
and repositories and plugins should be in another place (for parent).
* You can release master as your original suggestion. This is what I was
planning on doing anyway. We can even set you up to release master on
builds.sakaiproject to sonatype if it helps at all, it's pretty easy. The
most time consuming part is figuring out and updating the properties.

If we have lots of indies being released and tested (still unknown), the
version of master might be a lot higher than 2.9.1 by the 2.9.1 release.
Master releases in seconds so it's pretty trivial. The most annoying thing
is editing the XML which I'd like to automate. Right now I've got this each
version defined in 3 places.


On Sat, Nov 17, 2012 at 4:18 AM, David Horwitz <david.horwitz at uct.ac.za>wrote:

> Hi Steve,
>
>
> On 11/17/2012 11:11 AM, Steve Swinsburg wrote:
> > Hi David,
> >
> > Could you just get your local Samigo to not inherit from master,
> So in effect recreate pure-pom (or at least one of them)?
>
> >   and just roll whatever it needs from master into the samigo pom?
> Tried that it seems the inherited distribution management overides any
> local DM or defined versions
>
>
> D
> > cheers,
> > Steve
> >
> >
> > On 17/11/2012, at 6:51 PM, David Horwitz <david.horwitz at uct.ac.za>
> wrote:
> >
> >> Hi All,
> >>
> >> Here is the case we run a custom msub branch of Samigo - effectively we
> >> msub a later version (in 2.8 we ran sam 2.9 and in 2.9 it will likely be
> >> based on 2.10) that include new features we're contributing back. We
> >> reversion this (2.10.0-UCT) and cut regular releases from our jenkins
> >> build. The reversioning and cutting stable releases are required parts
> >> of our deployment in order to ensure that the correct code is deployed
> >> and to track changes etc.
> >>
> >>
> >> OK now in 2.9 we have to inherit from master - this causes problems
> >> because the released master defines versions for samigo api jars that
> >> are incorrect causing the build to fail. I can see no reliable way round
> >> this other than having a UCT release of master for every Samigo build (a
> >> master that would only be used for release purposes) am I missing
> >> something here?
> >>
> >> D
> >> _______________________________________________
> >> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20121117/66094245/attachment.html