I agree that this needs some rethinking in the light of experience.
We're in the process of releasing our second set of modules. This
sheds new light on the module version and release process discussions
we had earlier. It also raises some questions about how we ideally
want to handle certain scenarios now that we are forced to deal with
more than one release.
1) Should the first release of a new module use the prevailing version
at the time or do we intend to always start with the logical "1" of a
first release? For quiesce we used the prevailing version -
0.2-incubating.
If we had released quiesce at 0.1-incubating I guess that it should have
been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
there needs to be some guidance for developers because I don't think
it's obvious.
At the same time as introducing quiesce, changes were made to jpa -
which now depends on quiesce. So, if we were releasing jpa at
0.2-incubating it would need to depend on a release of quiesce created
at the same time and called 0.1-incubating.
2) How will we make multiple component versions available in the
future for download? If we always release all modules (as we did in
our 0.1 and 0.2 releases) then it's simple - we can create a download
page for each release and we can create documentation per release.
However, if we start to release the modules individually things get a
bit more complicated. One possibility is to move from one common
download page to a download page per module.
That would be OK if they were truly independent. I've drawn here the
dependencies that I observed when I was testing the 0.2-snapshot
release.
https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
The relationships indicated in the picture just show what happened when
I tried to build something - so for example, the jpa build failed with
missing dependencies until I had 'mvn install'd quiesce, util,
testsupport and parent.
3) Are there other benefits in keeping the module versions consistent
and concurrently releasing all modules rather than individual modules
that we haven't really considered? I'm thinking about things like
documentation, test validation, and samples.
The main point of the blog sample is to bring together a number of the
modules and show them working in one application, I think this might be
true of ariestrader too. Trying to think about how to maintain either of
these samples to work with a set of independently released modules is
making my head hurt.
Thinking more about #3 - It seems it might be very difficult to
maintain our documentation and samples once the module versions begin
to diverge. Changes to one module might force us to want to release
or update some other module, ... such as the case with (and perhaps
only with) samples. In fact, samples might be impacted by the release
of each module if we want to try to keep them as current as possible.
This might result in a proliferation of sample releases. Moreover,
the combination of modules/versions we use in our sample releases
might not demonstrate or validate a common set of modules/versions
that a user might choose. Yes, all valid versions based upon
dependencies *should* work fine together ... but that assumes nobody
makes mistakes. There is a certain comfort (from a user perspective)
in knowing that a particular set of modules has been tested together
in some fashion which can at least be partially demonstrated in our
samples.
I agree.
I understand why we started down the path of individual components and
I definitely agree that it has value ... I'm just rethinking the
decision now that we are doing our second release and have to deal
with multiple versions for the first time. The second release begins
to set the precedent for how we deal with some of these things. The
fact that we basically released everything again with a consistent
version makes me wonder if that should be our standard process instead
of individual component versions.
There are advantages in being able to release a module separately. For
example if we find something we need to fix in one module, and it's a
self contained fix, we could create a new release of that module quite
quickly. On the other hand, the slow part of the release process (72
hours for a vote, then another 72 for the incubator PMC?) remains the same.
On balance I'm in favour of a single release at a set level - however -
if we can find an absolutely crystal clear way to document a
release-by-module system I think it could work; I'm worried by the
complexity it would lead to in documentation and samples.
Zoë
