[Building Sakai] Patches vs Branches

[Matthew Jones]

Hi Steve,

I noticed nobody responded to you on this. We liked how gradebook2 did this
too. I discussed this on the dev list a few months ago as well. [1]
There are a few issues as you'd mentioned.

*If the project only has problems with dependencies moving around between
versions of Sakai*
For evaluation, this needed to be done so it could easily build, because the
it had dependencies that moved around between Sakai revisions. Luckily it
wasn't using any api's that changed in the kernel between 2.6 and 2.7. We
originally had an XSLT that did this transform from 2.5->2.6 but nothing for
2.7. Jim documented these changes (mostly scheduler and edu-services for
2.7) [2] and added profiles for evaluation in EVALSYS-811. [3] However, we
realized that if another project depends on a project with profiles maven
won't activate their profiles, so you have to also use property activation.
This was fixed in EVALSYS-1052. For now, both of these copied the gradebook2
model where you'd have profiles named sakai2.5, sakai2.6, sakai2.7, and
matching properties. I believe other projects also used this similarly.
You'd activate these with "mvn install -P <profilename>" or "mvn install -D
<propertyname>"

You still need to update the parent version, but that's pretty easy with a
shell script like gradebook2's. I'm also working on a better overall
solution for that, since the maven version plugin doesn't seem to do it.
https://source.sakaiproject.org/contrib/gradebook2/trunk/setSakaiVersion.sh

*If the project needs to use newer apis (from kernel or somewhere) in newer
versions*
We had this problem in basiclti because a new method "page.setTitleCustom" came
into existence in Sakai 2.7. I think there were some other changes. The
solutions we had were:
1) Provide a patch that the end user has to run to fix the code. (Ended up
being the easiest)
2) Use reflection to detect if the method exists or not, and run the
reflected code. (Seems like a good idea if performance isn't a concern) This
is actually recommended for Android development for backward compatibility
and *may* be the best way to go if it really matters. [5]
3) Provide local "wrapper" classes that are compiled with the
build-helper-maven-plugin
depending on which profile is activated. I actually did this back to
basiclti in this revision:
  https://source.sakaiproject.org/viewsvn?view=revision&revision=70037
With basiclti-util and 2 directories (pre-k1 and k1) which would be included
by maven depending on what it needed.  Each one had a slightly different
LocalEventTrackingService.java. However this was confusing to other
committers so it was removed. I'm still using this build-helper-maven-plugin
in our local providers so we can build a clean providers only including
selective providers.

Perhaps there's an option 4, but those seemed pretty good, oh right 4 might
be maintaining branches for every different version of Sakai. ;) Not very
desirable.

[1]
http://old.nabble.com/-Building-Sakai--Dependencies,-Indie-Projects-and-Contrib-td28993698.html
[2]
http://confluence.sakaiproject.org/display/REL/Mapping+dependencies+by+version
[3] http://jira.sakaiproject.org/browse/EVALSYS-811
[4] http://jira.sakaiproject.org/browse/EVALSYS-1052
[5]
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html

On Wed, Nov 10, 2010 at 9:41 AM, Steven Githens <swgithen at mtu.edu> wrote:

> Hi Dev,
>
> I'm getting ready to tag some Assignments2 release candidates in
> preparation for tagging a 1.0 soon, and was curious how people felt
> about patches vs branches, specifically how Gradebook2 handles them.
>
> Typically, for most tools we maintain a number of branches for 2.6, 2.7,
> etc etc.  However, I kind of like how Gradebook 2 just has a single
> checkout and then you run the minor patch for your version of Sakai.  If
> there were major changes between versions I could see having seperate
> branches, but if changes are very minor (mostly poms), this seems like a
> nice way to do it. ( I won't lie, I'm also a lazy programmer and don't
> like managing branches ).
>
> I'm curious how deployers feel about this who've installed Gradebook2
> and obviously tons of other Sakai tools.  Does the minor patch cause any
> issues or headaches when deploying, or does it fit in to your workflow
> fairly smoothly?  Any other considerations?   I probably want to start
> rolling tarballs next week.
>
> Maximum cheers,
> Steve
> _______________________________________________
> 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/20101117/b9d5de1d/attachment.html