Hi all,
A large portion of yesterdays meeting ended up being a discussion on
async releases. Mark (Diggory) has for some time been strongly
advocating this approach and has written extensively on the subject both
on the wiki and in Jira. I think it is incumbent on us all to consider
his arguments and comment thereon. So to give him a rest I'll chip in,
albeit from a different angle.
Some background - DSpace can currently be downloaded from Sourceforge
either as a source code or binary release.
The proposition (as I understand it) - Allow for releases of individual
DSpace Maven modules outwith the normal 'complete' release that
currently takes place roughly once a year. By a release I mean copying
the DSpace Maven artifacts (jars and wars) to the DSpace Maven
repository space to be publicly available.
So why do async releases ? There are a number of reasons, for example...
1. To fix a bug in module dspace-xxx we could just release that module.
2. Or make available new features without waiting for the annual
release.
3. Or release entire new modules
etc etc.
So how would this work ? The important thing to note is that it is
dependant on people using the binary release. If they wanted to pick up
a newly released version of a module they would just need to change the
version number of that module in the appropriate pom and rebuild their
local version of DSpace. Even better, we could distribute the binary
release with ranges of version numbers (Maven allows for <version>1.7.1,
1.7.2, etc) and then all they would have to do would be to rebuild and
it would automatically pick up the latest version. It is worth noting
that this is exactly what we already do for the language packs so this
is not new.
The problem (as I see it) - this all falls down if people have the
source code release. If people have the source code for a module in
their local installation then that is what they should be deploying.
Whilst it would be possible for them to change the dependencies in their
poms to pick up newly released artifacts from the Maven central repo I
don't think anyone would argue that it would be a good idea to have one
version of the source code in your installation, but actually deploy a
different one, too messy.
So, if you are a fan of the XMLUI and Maven overlays, a binary release
might well be sufficient for you. You can of course still check out the
code for any module that interests you from the DSpace SVN site.
However, if you are a JSPUI user and/or want or need to see the source
code in general, then you probably want a source code release. That way
you don't have to familiarise yourself with the DSpace SVN site.
Could we continue to do both a source and binary release as we do at
present ? Yes. Many of the modules that currently reside in trunk in SVN
would be moved into the modules directory so that they could be released
independently of one and other, and the assembly of the source code
release would pick up the source code from there rather than from trunk.
The downside of continuing with a source code release is that it
prevents us from unifying behind one approach and being able to make
announcements relating to new releases (async or otherwise) that apply
to everyone.
Personally, I am still in favour of source code releases. I don't see
DSpace as a framework on which people build their local customisations,
I see it as a complete implementation which people take and do what they
want with it.
Phew! I'm knackered.
Robin.
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
