You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/01/11 15:49:33 UTC
Smaller and Quicker Releases
Hi all,
Now, that the Jackrabbit 1.4 is just about going out of the house, I
want to restart a discussion, which has been lead a number of times but
IIRC always has been settled with something like "we know we should, but
we will not now" .... There is probable not a better time than just
after a release, to reconsider. So, let's go.
Each Jackrabbit Release is a real big shot. For example, release 1.4
contains 22 artifacts. Some of them are new (e.g. ocm, spi) some of them
have not changed at all (classloader, maybe more). This makes me worry a
bit:
* Coordinating the release of 22 artifacts is very difficult and close
to impossible
We have seen that in the delay of the release but also in the recent
veto vote due to an unfixed issue. It will not be getting easier in the
future as more artifacts are being used to a similar extend as
jackrabbit-core.
* Increasing the version number of an artifact which did not change is
problematic
As a user (with my Apache Sling hat on) I am kind of worried of the new
Jackrabbit API version: There have been constant version increses ever
since the artifact was created. As the Jackrabbit API is the official
access to some Jackrabbit functionality which is also available
remotely, I pay very much attention to the API and its changes.
If there are changes, I might consider upgrading the API library in
Sling. If there are none, I will of course not upgrade. But how can I
tell ? Usually, I check the version number. This increases, so my first
check fails. So I have to go ask SVN - not something really useful,
right ?
[ Maybe the API is wrong in the 1.4 release, but replace API with class
loader and think again ]
To come to an end, I suggest:
* We stop making big releases as we do now
* We release as appropriate and as required
This results in more releases but in a much faster release turnaround.
So for example to make an urgent release with the OCM component (just an
example), we would not have to wait for any other component being ready
for release. We just fix and release.
And even better: I am sure, we might even be able to prevent creating
branches :-)
WDYT ?
Regards
Felix
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
+1
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jukka,
++1
I think this is a very valuable strategy moving forward for our patch
releases. And it will probably also show, that we might handle the trunk
in a similar manner as we would start handling the branch(es).
Thanks for this proposal.
Regards
Felix
Am Montag, den 21.01.2008, 12:11 +0200 schrieb Jukka Zitting:
> Hi,
>
> We have a relatively short term need to do patch releases and I don't
> want to introduce too big changes in the 1.4 (and 1.3) branch, so
> here's a proposal for an intermediate solution for patch releases
> until we reach a better consensus on what to do in trunk. In fact I
> think we should use something like this even after (or if) we split
> Jackrabbit to subprojects.
>
> ----
>
> JACKRABBIT PATCH RELEASES
>
> Granularity
>
> A patch release will only contain a single Jackrabbit component. Bug
> fixes to multiple components will go out in multiple patch releases.
>
> Version control
>
> Bug fixes targeted to a patch release should first be committed in
> Jackrabbit trunk, and then merged (preferably using "svn merge" where
> possible) to the appropriate branch. Fixes to issues that are no
> longer present in trunk (for example because of some refactoring) can
> be committed directly to a branch.
>
> Once all planned bug fixes have been merged or committed to the branch
> and any administrative changes (version number update, etc.) have been
> made, the component to be released will be tagged from the branch
> using a command like:
>
> svn copy -m 'x.y: Tagged component-x.y.z' \
> https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \
> https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z
>
> The contents of the tag should never be changed.
>
> Issue tracker
>
> Patch releases will be tracked by assigning each of them a separate
> component-version (e.g. jackrabbit-core-1.4.2) tag in the issue
> tracker. All bug fixes to be included in a patch release should be
> tagged with the respective version tag.
>
> Note that this will likely cause problems later on by inflating the
> list of release versions, but hopefully by that time we have split the
> release process to more manageable subprojects.
>
> Parent POM
>
> The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not
> be changed or included in a patch release. A component POM needs to
> explicitly override parent settings if it needs such changes in a
> patch release.
>
> Note that POM changes (apart from version updates) should normally not
> be needed in patch releases.
>
> Patch dependencies
>
> Bug fixes in patch releases should normally not depend on changes in
> other components or external dependencies. In case they do (and there
> is a solid reason for doing that), such updated dependencies should be
> explicitly declared in the component POM and clearly described in the
> patch release notes.
>
> Announcements
>
> Normal patch releases will be announced on the Jackrabbit dev@,
> users@, and announce@ mailing lists, but not on announce@apache.org.
> Patch releases containing fixes to critical security issues will also
> be announced on announce@apache.org.
>
> ----
>
> WDYT?
>
> BR,
>
> Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> Think about Jackrabbit 1.4 and tell me how a better test suite would have noticeably expedited the release?
I didn't actually answer your question. Let me give you an example:
"Refactor DBMS support for JNDI datasources":
http://issues.apache.org/jira/browse/JCR-1309
This feature was very simple to implement, and it is committed in the
trunk already. Unfortunately, it just missed the 1.4 'deadline'. Who
wants to use it will have to wait for Jackrabbit 1.5 (unless they use
'nightlies', which is dangerous). Having a better test suite would
allow shorter release cycles. If we had a two week release cycle,
JCR-1309 would be available next week. Maybe this particular feature
would still be marked 'experimental', but it would be included in a
release.
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> > With an automated release process, we can release more often.
> We can, but should we?
I think, we should release more often. Release early. Release often.
And listen to your customers:
(http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html).
To release often, we need better tests and a automated release
processes. Better tests, otherwise changes would be too risky.
Automated release processes, otherwise a release takes too much time.
> Think about Jackrabbit 1.4 and tell me how a better test suite would have noticeably expedited the release?
A good test suite should improve software quality and reduce the risk
of changes. Automated release processes save time. Unfortunately both
(writing tests and automating processes) is an investment and takes
time.
> change our releasing strategy to time-driven
That's an option, but not really required. Most features can be split,
and the first release will only contain a subset of the planned
functionality. This helps getting feedback. What I mean is Agile
software development
(http://en.wikipedia.org/wiki/Agile_software_development).
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 27, 2008 10:46 AM, Thomas Mueller <th...@gmail.com> wrote:
> A good test suite would make changes less risk. With an automated
> release process, we can release more often.
We can, but should we?
You have two points, "better test suite and/or automation" and "more
frequent releases", but I don't see the clear connection between them.
Think about Jackrabbit 1.4 and tell me how a better test suite would
have noticeably expedited the release? The same applies for automating
the release process.
The release schedule is driven by features to be included in the
release and not constrained by lack of automation or testing. What you
seem to really be proposing here is not increased automation but a
change in our releasing strategy from feature-driven to time-driven.
I'm willing to debate the merits of that, but let's be clear on what
we are discussing about.
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi Roland,
Thanks for you very detailed response! I just read the book "The
Elements of Style" and will try to make my response short to save
readers time.
The Jackrabbit release process is manual, and takes a lot of peoples
times. Automating the process also takes time, and it doesn't make
sense to do it if you don't release often. But automating doesn't hurt
quality, and if we want to release more often, we need to automate
some steps. Voting is still possible, but releasing would be a lot
easier.
Jackrabbit is good quality software: it is well tested, because it is
used by many people, and bugs are fixed as they are found. It doesn't
have a great test suite, but the code is 'time-tested'. This offsets
the lack of unit tests. The problem is: changing Jackrabbit is
dangerous. We can't release often and need to maintain a branch.
A good test suite would make changes less risk. With an automated
release process, we can release more often. We do have the resources
to do that. Automated GUI testing is hard, but Jackrabbit is not such
an application, so automated testing is possible. What I have
automated in my project (H2):
- Platform testing (OS, JVM)
- Code coverage testing
- Performance testing
- Running unit tests of software that depends on it
- Test if Javadocs are complete
- Documentation spell checking
- File header checking
- Check if all XML is well-formed (including XHTML)
- (HTML-) link checking
Many of that is currently not done for Jackrabbit. Not all needs to be
done. But with all that, changing the code is less risky, and
releasing is a lot easier and quicker. You can list tested operating
system, databases, file systems, and virtual machines. With a good
test suite, users that want to use Jackrabbit on an unsupported
platform just need to run the tests. People that want to use different
versions of Jackrabbit dependencies can use OSGi or run all tests with
his version of the dependency.
Short release cycles are possible with all kinds of software. You can
do that with operating systems, you can do that with databases (H2).
You can do it where the API and behavior is well defined. With
Jackrabbit, it is: the JCR API is quite stable. There will be a
problem with JCR 2.0, but multiple incompatible API versions can be
supported using a preprocessor. For details, see
http://h2database.googlecode.com/svn/trunk/h2/src/main/org/h2/jdbc/JdbcConnection.java
(look for //#ifdef). Internal Jackrabbit APIs are also quite stable
(the PersistenceManager API for example), and new features can be
introduced using new interfaces.
> a bug is uncovered in an older release. The bug
> is reported, maybe even with a patch. And you want to tell
> them: "Duh, that release is 6 months old. We've had 12 new
> releases since, upgrade to the latest one first and if the
> bug is still in there, provide a new fix for that."?
Tell them: "Read the release notes between your release and now. If
there are breaking changes, disable the relevant system properties /
settings. Then try the newest release." Of course you can't help those
that don't have good tests, and at the same time rely on undocumented
behavior - for those, you would probably need individual bugfix
branches, where only the problems they ran into are fixed.
> Agile software development requires excellent test coverage.
Excellent software requires excellent tests. Functional test coverage,
and code coverage. Do you know Crap4J (http://www.crap4j.org)? It's
not perfect, but the idea is good.
> hard to attract volunteers if you require them to provide full test coverage
Stable software is more important than having many volunteers. With
unstable software you drive away customers. You also drive away good
developers because they always have to clean up the mess of those that
don't test. There is a 'sandbox' to try out things.
> That does _not_ mean there shouldn't be more test coverage ;-)
Yes, but we need to agree we want that. We need to define the target,
and the process.
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Roland Weber <os...@dubioso.net>.
Hello Thomas,
> About my idea for two week release cycles. Probably most of you think
> this is unrealistic or bad.
Unrealistic at Apache, yes.
> - Fully automated releases
Apache projects are also running integration builds like Gump [1]
and continuous integration engines like Continuum. [2] You can
download the packages generated by such builds, for example at [3]
for JMeter. And of course you can always grab the source of some
project from trunk and build it yourself. Such packages are called
nightlies or snapshots, but they are not and cannot be _releases_
at Apache.
[1] http://vmgump.apache.org/gump/public/
[2] http://vmbuild.apache.org/continuum/
[3] http://people.apache.org/builds/jakarta-jmeter/nightly/
An official Apache release MUST be reviewed and approved by the
responsible Project Management Committee (PMC). This is one of
the major differences between Apache and a simple OSS project
hoster. It is Apache policy, and projects that don't like this
policy must be hosted elsewhere. PMC review means that pre-release
packages are created and made accessible for the review. The PMC
members and other interested volunteers then access these packages
and check them for formal compliance with Apache requirements and
for technical correctness. Although unit tests and tools like RAT
help with some of these tasks, it is inherently a manual thing.
The review must be done by the _persons_ that are PMC members.
They can use tools, but the cannot delegate their responsibility
towards Apache to a piece of software. A vote is held on publishing
the release, and the votes need to be cast manually. Three days is
the typical voting period for release votes, so that is the minimum
delay for publishing a release.
The formal review includes checking that license headers in the
sources are correct (RAT does that), that the LICENSE and NOTICE
files are in the proper locations, and that their contents matches
the contents of the archive. See [4] for a recent example where
that was not the case. There are attempts to automatically generate
NOTICE files, but the results are unsatisfactory and there has
been a huge discussion [5,6] about it on legel-discuss@ recently.
The technical review can also lead to unpleasant surprises. For
example, the release of HttpCore beta1 this month was delayed by
a week. When pre-release packages became available [7], the reviewers
tried them on different OSes with different Java versions and
different numbers of CPUs, and the testcases that always passed
on the developer machines started failing in some combinations.
We don't have the hardware, software licenses, or administrator
time that would be needed to run a fully automated test suite
in a variety of environments. I believe the same is true for
every other Apache project.
Most committers and PMC members here at Apache are volunteers that
spend their spare time on contributing, and many are active in
several projects. You can't expect the reviewers to go through
this routine every two weeks for a single (or every?) project.
That's for the review part. Preparing a release also takes some
time, as Jukka pointed out. Even if you generate release notes
from JIRA, somebody has to sift through the issues and make sure
they are tagged correctly so the generated release notes match
the package that is being built. Then there should be a paragraph
or two explaining the significant changes since the last release.
The actual publishing includes copying files to dist locations
(can be done by script), updating release numbers and download
links, putting a News item on the web page, and sending out an
announcement mail. Shouldn't take more than an hour, but an hour
of spare time to spend every two weeks is summing up to a lot
of time that could be spend otherwise.
[4]
http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/%3c25aac9fc0801240857s3ae93ee6h8f2881bf102ce233@mail.gmail.com%3e
[5]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200712.mbox/%3c25aac9fc0712171137q67c3a7cfu5012b10da9f52725@mail.gmail.com%3e
[6]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3c478CEE8B.60202@apache.org%3e
[7]
http://mail-archives.apache.org/mod_mbox/hc-dev/200801.mbox/%3c1200393145.9281.28.camel@ubuntu%3e
> - No branches
> - Only one file without dependencies
What you are suggesting are techniques from an approach that
is called "Agile Programming". I've seen Agile Programming
at work and function well. You have provided some examples,
too. But the cases where I know it has worked have two things
in common, and your eBay example matches these as well:
1) The projects were at the top of the software stack.
2) The projects were staffed with payed developers.
So eBay rolls out a new release of their software every two
weeks. I bet you they don't update their OS, database,
web server or other lower layers of their software stack
with the same frequency. One golden rule of system administration
is to "Never change a running system". It has a mirror rule
which is "Never run a changing system". Keeping the system
environment stable allows them to test their application
in that environment well. This testing offsets the risk
introduced by the frequent code changes.
Jackrabbit and other OSS projects are not at the top of the
software stack. Users that apply the Agile Programming technique
themselves would be able to integrate frequent releases.
But users that have a more traditional release cycle of
their own software, or that are trying to keep their
software stack stable and minimize the risk introduced
by changes will simply not be able to deal with that.
Say that a bug is uncovered in an older release. The bug
is reported, maybe even with a patch. And you want to tell
them: "Duh, that release is 6 months old. We've had 12 new
releases since, upgrade to the latest one first and if the
bug is still in there, provide a new fix for that."?
I don't believe that most users would find this appealing.
You have suggested to keep default behavior stable to allow
for such updates. You would also need to keep all APIs
stable. That in itself is a problem even for standard APIs.
For example, I had to deal with a change in the Servlet API
(I think from 2.2 to 2.3) where the method signature was
the same, but the path in the HttpServletRequest was split
differently for default servlets in the newer API. To make
matters worse, IBM initially overlooked that change in the
specification and implemented it later in a fixlevel. So
with some fix version of the application server, my code
would suddenly start to produce wrong results. In the end,
I had to implement a configuration switch for the servlet
because on the newer API it was impossible to correctly
detect the case through the standard API.
Now imagine that not only the standardized API, but also
the Jackrabbit specific APIs would have to be kept stable,
along with the default behavior. That in itself is a
contradiction of the Agile Programming model. AP is all
about allowing frequent changes and managing the risk
through good test coverage. You can do that easily at
the top of a software stack, but not in the foundation.
Yes, another golden rule for OSS projects says "release early,
release often". That is necessary to attract a developer
community. But stable branches are created and maintained
for the users with a conservative approach to running their
systems, and I don't think an OSS project with the scope of
Jackrabbit can afford to leave those users behind.
Now to the second point, payed developers. AP requires
excellent test coverage. OSS requires volunteers. You will
find it very hard to attract volunteers if you require
them to provide full test coverage for everything they do,
even if they are just trying something out and know they
will have to change that implementation (and all testcases
for it) later on. Even worse if you want to suspend
development of the project until the test coverage is
over 90%.* Payed developers do what they get paid for,
volunteers will just go looking for a more interesting
project to spend their time on.
*) If you can test 100% of the functionality without
testing 100% of the code, you've got dead code ;-)
The technical points you raised can be countered too.
No dependencies means that you have to package every
dependency into your file(s). That is OK if you are at the
top of the software stack and want just an EAR file to
deploy on an application server. But it sucks if you
are offering components for others to build their stack.
The users may be on different fixlevels of dependencies
that are used in their own code too. In some cases, it is
also impossible for Apache projects to bundle dependencies
because of licensing issues.[8]
The no-branches approach with "experimental" switches
in the code does not necessarily improve code quality.
But the major problem is the missing code stability
for conservative users pointed out above.
[8] http://people.apache.org/~rubys/3party.html
At this point, I'd like to iterate something that
Jukka wrote in this thread: Thanks for bringing this
radically different idea into the discussion!
Suggestions from a totally different point of view
are a good thing. Even if they are not adopted, they
require reconsideration of the status quo. In this
particular case, I believe that your suggestions
are not applicable to the nature and environment of
the project. That does _not_ mean there shouldn't
be more test coverage ;-)
cheers,
Roland
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
About my idea for two week release cycles. Probably most of you think
this is unrealistic or bad. Yesterday I found a project that has a
release cycle (stable releases) of 4 days on average. Sometimes two
releases per day, and sometimes no release in two weeks:
Hudson (continuous integration engine)
https://hudson.dev.java.net/
They seem to have (as far as I can tell):
- Fully automated releases
- No branches
- Only one file without dependencies
I have tested Hudson yesterday evening, and it seems to be stable.
There are other projects, for example H2 (http://www.h2database.com)
has a two week release cycle. Another link I just found about release
cycle:
2 Year Release Cycle? How About 2 Week Release Cycle (eBay)
http://alanlewis.typepad.com/weblog/2005/11/2_year_release_.html
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Marcel Reutegger <ma...@gmx.net>.
+1
regards
marcel
Jukka Zitting wrote:
> Hi,
>
> We have a relatively short term need to do patch releases and I don't
> want to introduce too big changes in the 1.4 (and 1.3) branch, so
> here's a proposal for an intermediate solution for patch releases
> until we reach a better consensus on what to do in trunk. In fact I
> think we should use something like this even after (or if) we split
> Jackrabbit to subprojects.
>
> ----
>
> JACKRABBIT PATCH RELEASES
>
> Granularity
>
> A patch release will only contain a single Jackrabbit component. Bug
> fixes to multiple components will go out in multiple patch releases.
>
> Version control
>
> Bug fixes targeted to a patch release should first be committed in
> Jackrabbit trunk, and then merged (preferably using "svn merge" where
> possible) to the appropriate branch. Fixes to issues that are no
> longer present in trunk (for example because of some refactoring) can
> be committed directly to a branch.
>
> Once all planned bug fixes have been merged or committed to the branch
> and any administrative changes (version number update, etc.) have been
> made, the component to be released will be tagged from the branch
> using a command like:
>
> svn copy -m 'x.y: Tagged component-x.y.z' \
> https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \
> https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z
>
> The contents of the tag should never be changed.
>
> Issue tracker
>
> Patch releases will be tracked by assigning each of them a separate
> component-version (e.g. jackrabbit-core-1.4.2) tag in the issue
> tracker. All bug fixes to be included in a patch release should be
> tagged with the respective version tag.
>
> Note that this will likely cause problems later on by inflating the
> list of release versions, but hopefully by that time we have split the
> release process to more manageable subprojects.
>
> Parent POM
>
> The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not
> be changed or included in a patch release. A component POM needs to
> explicitly override parent settings if it needs such changes in a
> patch release.
>
> Note that POM changes (apart from version updates) should normally not
> be needed in patch releases.
>
> Patch dependencies
>
> Bug fixes in patch releases should normally not depend on changes in
> other components or external dependencies. In case they do (and there
> is a solid reason for doing that), such updated dependencies should be
> explicitly declared in the component POM and clearly described in the
> patch release notes.
>
> Announcements
>
> Normal patch releases will be announced on the Jackrabbit dev@,
> users@, and announce@ mailing lists, but not on announce@apache.org.
> Patch releases containing fixes to critical security issues will also
> be announced on announce@apache.org.
>
> ----
>
> WDYT?
>
> BR,
>
> Jukka Zitting
>
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
We have a relatively short term need to do patch releases and I don't
want to introduce too big changes in the 1.4 (and 1.3) branch, so
here's a proposal for an intermediate solution for patch releases
until we reach a better consensus on what to do in trunk. In fact I
think we should use something like this even after (or if) we split
Jackrabbit to subprojects.
----
JACKRABBIT PATCH RELEASES
Granularity
A patch release will only contain a single Jackrabbit component. Bug
fixes to multiple components will go out in multiple patch releases.
Version control
Bug fixes targeted to a patch release should first be committed in
Jackrabbit trunk, and then merged (preferably using "svn merge" where
possible) to the appropriate branch. Fixes to issues that are no
longer present in trunk (for example because of some refactoring) can
be committed directly to a branch.
Once all planned bug fixes have been merged or committed to the branch
and any administrative changes (version number update, etc.) have been
made, the component to be released will be tagged from the branch
using a command like:
svn copy -m 'x.y: Tagged component-x.y.z' \
https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \
https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z
The contents of the tag should never be changed.
Issue tracker
Patch releases will be tracked by assigning each of them a separate
component-version (e.g. jackrabbit-core-1.4.2) tag in the issue
tracker. All bug fixes to be included in a patch release should be
tagged with the respective version tag.
Note that this will likely cause problems later on by inflating the
list of release versions, but hopefully by that time we have split the
release process to more manageable subprojects.
Parent POM
The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not
be changed or included in a patch release. A component POM needs to
explicitly override parent settings if it needs such changes in a
patch release.
Note that POM changes (apart from version updates) should normally not
be needed in patch releases.
Patch dependencies
Bug fixes in patch releases should normally not depend on changes in
other components or external dependencies. In case they do (and there
is a solid reason for doing that), such updated dependencies should be
explicitly declared in the component POM and clearly described in the
patch release notes.
Announcements
Normal patch releases will be announced on the Jackrabbit dev@,
users@, and announce@ mailing lists, but not on announce@apache.org.
Patch releases containing fixes to critical security issues will also
be announced on announce@apache.org.
----
WDYT?
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Florent Guillaume <fg...@nuxeo.com>.
Jukka Zitting wrote:
>> * jackrabbit-jcr-tests: Some fixes now and then ... I would make this
>> a separate cluster
>
> Quite a few actually, jcr-tests is one of our more actively developed
> components.
>
> Architecturally it would warrant it's own subproject (like JCRTCK),
> but I pooled it in the core project to keep the number of subprojects
> manageable. There is also little end-user demand for jcr-tests.
>
> But yes, if we want to split down the core JCR subproject, I would
> first go with JCRTCK and only after that start considering any other
> splittings.
+1, as JSR-283 approaches and more people start to implement it, the
need for a cleanly separate JIRA project to track spec/TCK-related
problems will increase.
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 21, 2008 10:18 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Samstag, den 19.01.2008, 21:23 +0100 schrieb Roland Weber:
> > The latter requires a new component build process, hence effort.
>
> Definitely is this required ! Currently it looks like Jukka is just
> doing a "mvn release" on the jackrabbit branch root, thus incrementing
> versions, tagging and packaging each component (aka module) refereced in
> the root pom.xml.
Actually I do the "mvn release" tasks manually, as I'm not too
comfortable with the idea of the build environment automatically
committing stuff in svn. But the basic sequence is the same.
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Roland,
Am Samstag, den 19.01.2008, 21:23 +0100 schrieb Roland Weber:
> Hi Felix,
>
> >>> > > * jackrabbit-classloader: There isn't much work going on here, apart
> >>> > > from bugfixing. So there will be no reasons for new releases !
> >> >
> >> > Even bug fixes need to be released. Are you suggesting we just drop
> >> > the component?
> >
> > Definitely not, there will be bugfixes and we will not drop this. But we
> > should certainly not raise the version number and create new releases
> > just for fun. I would say the classloader component is largely in
> > maintenance mode at the moment.
> > [...]
> > Again: No changes, no release, no management. Therefore we should strive
> > for this separation.
>
> I don't quite understand how you would want to handle these "no release"
> components.
By "no release" I mean, that there no "mvn release" call is done with
the consequence of raising the version number, tagging etc. Of course we
still distribute these components.
> Just depend on the released 1.4 version and delete the code
> from trunk? Or move them to a separate component in the trunk already?
Of course, each component in Jackrabbit should always depend on a
released version of any other component, be it external or internal to
Jackrabbit, with the exception of dependencies on functionality added
after the release.
For example: Consider jackrabbit-core and jackrabbit-api: As long as
there is no change in jackrabbit-api, jackrabbit-core 1.5-SNAPSHOT still
depends on jackrabbit-api 1.4. After an addition to jackrabbit-api,
which is used by jackrabbit-core, the latter will be modified to depend
on jackrabbit-api 1.5-SNAPSHOT.
But of course, everything we are still working on remains in trunk.
> The latter requires a new component build process, hence effort.
Definitely is this required ! Currently it looks like Jukka is just
doing a "mvn release" on the jackrabbit branch root, thus incrementing
versions, tagging and packaging each component (aka module) refereced in
the root pom.xml.
What I envision is, that the "mvn release" is called on each module
separately as appropriate and required.
This also requires that we split the root pom.xml into two (as is also
done in Apache Felix and Apache Sling and works quite well): One
aggregator pom.xml at the root, which just contains the module
references and a separate real parent pom.xml in its own subfolder.
> Where
> should issues be reported? To the JIRA for the "main" cluster, where there
> is still a JIRA component for the spun-off code? Or create the new JIRA
> project right away? That would imply effort again, at least at Infra.
> And if you don't do the preparations right away, you'll face a steep hill
> to climb if there is need for a new release.
Not sure, whether this is really required right away. I think, the
problem with JIRA is somewhat overstated. I don't think, that it is this
problematic. We may well keep the current single-project setup but we
will have to more intensly manage the version numbers.
>
> A reasonable approach seems to be to start with the undisputed components
> (JCRAPI, JCRSPI, JCRRMI) and learn by doing how much effort it is.
> Additional projects can always be spun off from the "main" cluster later.
+1
Regards
Felix
Re: Smaller and Quicker Releases
Posted by Roland Weber <os...@dubioso.net>.
Hi Felix,
>>> > > * jackrabbit-classloader: There isn't much work going on here, apart
>>> > > from bugfixing. So there will be no reasons for new releases !
>> >
>> > Even bug fixes need to be released. Are you suggesting we just drop
>> > the component?
>
> Definitely not, there will be bugfixes and we will not drop this. But we
> should certainly not raise the version number and create new releases
> just for fun. I would say the classloader component is largely in
> maintenance mode at the moment.
> [...]
> Again: No changes, no release, no management. Therefore we should strive
> for this separation.
I don't quite understand how you would want to handle these "no release"
components. Just depend on the released 1.4 version and delete the code
from trunk? Or move them to a separate component in the trunk already?
The latter requires a new component build process, hence effort. Where
should issues be reported? To the JIRA for the "main" cluster, where there
is still a JIRA component for the spun-off code? Or create the new JIRA
project right away? That would imply effort again, at least at Infra.
And if you don't do the preparations right away, you'll face a steep hill
to climb if there is need for a new release.
A reasonable approach seems to be to start with the undisputed components
(JCRAPI, JCRSPI, JCRRMI) and learn by doing how much effort it is.
Additional projects can always be spun off from the "main" cluster later.
cheers,
Roland
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Am Montag, den 14.01.2008, 12:52 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 14, 2008 10:28 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > Am Sonntag, den 13.01.2008, 16:21 +0200 schrieb Jukka Zitting:
> > > JCR (the current Jira project)
> > > [...]
> >
> > Wow ! I think this should still be split:
>
> I don't see how you could end up with a manageable number of
> subprojects if you want to split down this one. I used the vague
> number of past cross-component issues as a way to group things
> together, and this core cluster came up as the most interdependent set
> of components. We probably should strive to split it down at some
> point, but only after we've first done the required refactoring work.
>
> As mentioned in my previous message, I want our codebase to drive the
> organizational boundaries, not the other way around.
>
> > * jackrabbit-jcr-commons: Is very much API like, so we could move it
> > to the API cluster, right ?
>
> Not really. There's lots of implementation classes (with
> implementation bugs) there and traditionally the component has been
> tightly coupled with jackrabbit-core. Much of it's original contents
> (the name, util, uuid, and value packages) are essentially just parts
> of jackrabbit-core that could be extracted to a separate component due
> to having no dependencies to other parts of the core. I think much of
> that code is much better located in spi-commons where it actually can
> and will be reused by multiple backends.
>
> The new stuff in o.a.j.commons has IMHO a clearer architectural
> separation to jackrabbit-core and thus could warrant separate
> releases, but until we have deprecated and removed the rest of the
> component I don't think we should take separate jcr-commons too far
> from core.
>
> > * jackrabbit-spi-commons, -jcr2spi, -spi2jcr: These are the SPI
> > cluster
>
> I was actually even considering including jackrabbit-spi in the core
> cluster as an internal component until it's more stabilized (at some
> point we need to start considering backwards compatibility for all spi
> changes). The spi implementation components (at least spi-commons and
> jcr2spi) are code-wise quite related to core and jcr-commons, and
> quite recently we were still moving large chunks of code between these
> components. I don't think we've yet reached an architecturally stable
> componentization there and we still should make core depend on jcr2spi
> to avoid duplicate code, so IMHO it's premature to split these SPI
> components to a separate subproject.
After all these words I have to come to the conclusion, that all this
code looks somewhat convoluted ... So, we have to keep this cluster ...
>
> > * jackrabbit-classloader: There isn't much work going on here, apart
> > from bugfixing. So there will be no reasons for new releases !
>
> Even bug fixes need to be released. Are you suggesting we just drop
> the component?
Definitely not, there will be bugfixes and we will not drop this. But we
should certainly not raise the version number and create new releases
just for fun. I would say the classloader component is largely in
maintenance mode at the moment.
>
> > * jackrabbit-text-extractors: Is this a movable target ? Otherwise, I
> > don't see much release work here ...
>
> We need to keep text-extractors around until we can replace the
> functionality with Apache Tika or something like that. We had one
> change (JCR-1247) to text-extractors in 1.4, and there might well be
> bug fixes or other minor changes that we need to do before we can drop
> the component.
By "movable target" I meant: This is probably in maintenance mode just
like the class loader. Of course, if there were changes to this before
the latest release, there is a new version released. But same as with
class loader, no release and version number incrementing just for fun.
>
> > * jackrabbit-jcr-tests: Some fixes now and then ... I would make this
> > a separate cluster
>
> Quite a few actually, jcr-tests is one of our more actively developed
> components.
>
> Architecturally it would warrant it's own subproject (like JCRTCK),
> but I pooled it in the core project to keep the number of subprojects
> manageable. There is also little end-user demand for jcr-tests.
>
> But yes, if we want to split down the core JCR subproject, I would
> first go with JCRTCK and only after that start considering any other
> splittings.
ACK.
>
> > > JCRWEB
> >
> > I would separate these, too: -jcr-server and -webdav in one cluster,
> > -jcr-servlet and -webapp in another one.
>
> That may make sense architecturally, but again we should keep the
> number of subprojects down to a manageable level.
Again: No changes, no release, no management. Therefore we should strive
for this separation.
Regards
Felix
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 14, 2008 10:28 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Sonntag, den 13.01.2008, 16:21 +0200 schrieb Jukka Zitting:
> > JCR (the current Jira project)
> > [...]
>
> Wow ! I think this should still be split:
I don't see how you could end up with a manageable number of
subprojects if you want to split down this one. I used the vague
number of past cross-component issues as a way to group things
together, and this core cluster came up as the most interdependent set
of components. We probably should strive to split it down at some
point, but only after we've first done the required refactoring work.
As mentioned in my previous message, I want our codebase to drive the
organizational boundaries, not the other way around.
> * jackrabbit-jcr-commons: Is very much API like, so we could move it
> to the API cluster, right ?
Not really. There's lots of implementation classes (with
implementation bugs) there and traditionally the component has been
tightly coupled with jackrabbit-core. Much of it's original contents
(the name, util, uuid, and value packages) are essentially just parts
of jackrabbit-core that could be extracted to a separate component due
to having no dependencies to other parts of the core. I think much of
that code is much better located in spi-commons where it actually can
and will be reused by multiple backends.
The new stuff in o.a.j.commons has IMHO a clearer architectural
separation to jackrabbit-core and thus could warrant separate
releases, but until we have deprecated and removed the rest of the
component I don't think we should take separate jcr-commons too far
from core.
> * jackrabbit-spi-commons, -jcr2spi, -spi2jcr: These are the SPI
> cluster
I was actually even considering including jackrabbit-spi in the core
cluster as an internal component until it's more stabilized (at some
point we need to start considering backwards compatibility for all spi
changes). The spi implementation components (at least spi-commons and
jcr2spi) are code-wise quite related to core and jcr-commons, and
quite recently we were still moving large chunks of code between these
components. I don't think we've yet reached an architecturally stable
componentization there and we still should make core depend on jcr2spi
to avoid duplicate code, so IMHO it's premature to split these SPI
components to a separate subproject.
> * jackrabbit-classloader: There isn't much work going on here, apart
> from bugfixing. So there will be no reasons for new releases !
Even bug fixes need to be released. Are you suggesting we just drop
the component?
> * jackrabbit-text-extractors: Is this a movable target ? Otherwise, I
> don't see much release work here ...
We need to keep text-extractors around until we can replace the
functionality with Apache Tika or something like that. We had one
change (JCR-1247) to text-extractors in 1.4, and there might well be
bug fixes or other minor changes that we need to do before we can drop
the component.
> * jackrabbit-jcr-tests: Some fixes now and then ... I would make this
> a separate cluster
Quite a few actually, jcr-tests is one of our more actively developed
components.
Architecturally it would warrant it's own subproject (like JCRTCK),
but I pooled it in the core project to keep the number of subprojects
manageable. There is also little end-user demand for jcr-tests.
But yes, if we want to split down the core JCR subproject, I would
first go with JCRTCK and only after that start considering any other
splittings.
> > JCRWEB
>
> I would separate these, too: -jcr-server and -webdav in one cluster,
> -jcr-servlet and -webapp in another one.
That may make sense architecturally, but again we should keep the
number of subprojects down to a manageable level.
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Am Sonntag, den 13.01.2008, 16:21 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 13, 2008 4:02 PM, Roland Weber <os...@dubioso.net> wrote:
> > You'll have to use separate JIRA projects.
>
> Agreed, that's the cleanest solution.
>
> > > Either way we'll end up with problems if we have an issue that
> > > affects more than one component at a time.
> >
> > You'll create separate issues and link them. Either as subtasks,
> > or "depends on" or "blocks". Plenty of options there.
>
> Yep. My main concern is that we'd add quite a bit of procedural
> overhead since quite a few of our current issues affect more than one
> component. I guess that with a sensible grouping of components (see
> below) we could keep that overhead manageable.
>
> > However, I strongly suggest that you don't put 22 artifacts on
> > separate release cycles.
>
> +1
>
> > I recommend to shoot for a manageable 5 or 6 independent
> > release cycles.
>
> How about the following seven subproject groupings:
>
> JCRAPI
> jackrabbit-api
>
> JCRSPI
> jackrabbit-spi
>
> JCR (the current Jira project)
> jackrabbit-core
> jackrabbit-jcr-commons
> jackrabbit-spi-commons
> jackrabbit-jcr2spi
> jackrabbit-spi2jcr
> jackrabbit-classloader
> jackrabbit-text-extractors
> jackrabbit-jcr-tests
>
> (Note that core and the SPI implementation components are already
> somewhat related, and should become more and more integrated as we go
> forward, so splitting them to separate subprojects doesn't sound good
> to me at this point.)
Wow ! I think this should still be split:
* jackrabbit-jcr-commons: Is very much API like, so we could move it
to the API cluster, right ?
* jackrabbit-core: Is big in itself. This would warrant its own
cluster
* jackrabbit-spi-commons, -jcr2spi, -spi2jcr: These are the SPI
cluster
* jackrabbit-classloader: There isn't much work going on here, apart
from
bugfixing. So there will be no reasons for new releases !
* jackrabbit-text-extractors: Is this a movable target ? Otherwise, I
don't see much release work here ...
* jackrabbit-jcr-tests: Some fixes now and then ... I would make this
a
separate cluster
>
> JCRRMI
> jackrabbit-jcr-rmi
>
> JCROCM
> jackrabbit-ocm
> jackrabbit-ocm-nodemanagement
>
> JCRWEB
> jackrabbit-jcr-server
> jackrabbit-jcr-servlet
> jackrabbit-webapp
> jackrabbit-webdav
I would separate these, too: -jcr-server and -webdav in one cluster,
-jcr-servlet and -webapp in another one.
>
> JCRJCA
> jackrabbit-jca
Regards
Felix
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I know the chances for my proposal are low ;-) Just brainstorming.
> > - Add a lot of tests (functional coverage 100%, code coverage >90%)
> Who's going to write all those tests?
Mainly Jackrabbit developers, but also users. More automated tests
would improve the quality no matter what the release cycle is. But a
short release cycle requires more tests.
> > - Only check in fully tested features (or mark them as "beta")
> Then where do we work together?
> We need somewhere where we can try
> out, comment on, and co-develop new features (cf. ISM locking, data
> store, indexing enhancements, etc.).
We could use 'compile time' (constants) or 'run time' switches (system
properties) to enable new features (or make them the default) after we
consider them stable. Old code is removed when no longer needed.
> parts of the release process:
> schedule/fix issues
I would argue that's an ongoing effort.
> test
Tests should be run automatically in different environments.
> Review/vote on the release
Because it's only 2 weeks, people still know what was changed, so this
becomes easier. And people would just vote on what settings to enable.
> > - Release every 2 weeks
> Then what's the difference between a release and an svn checkout?
Not much: releases would have no failed tests on target platforms.
> we should only make feature release whenever we reach a reasonably
> stable state
Sure! So would need to make sure the trunk (with default settings)
doesn't get unstable ;-)
> This will likely
> always take longer than 2 weeks for any non-trivial enhancements.
Yes, but with compile / run time switches those are not a problem.
> What about production environments where you just want bug fixes to a
> well tested base release instead of code from the bleeding edge?
With enough automated tests the trunk would be more stable than
releases are now (at least that's the idea :-)
> > - Only one jar file
> What about people that just want to depend on our tools that work on
> top of the JCR API?
I didn't think about that - OK three jar files: API, core, tools
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 14, 2008 10:24 AM, Thomas Mueller <th...@gmail.com> wrote:
> I know this is radical, anyway:
Thanks, good to have also radically different viewpoints! I'm going to
shoot it down below, but you certainly have some good points that we
probably should adopt in one way or another.
> - Add a lot of tests (functional coverage 100%, code coverage >90%)
Who's going to write all those tests?
> - Only check in fully tested features (or mark them as "beta")
Then where do we work together? We need somewhere where we can try
out, comment on, and co-develop new features (cf. ISM locking, data
store, indexing enhancements, etc.). What better place to do that than
trunk? (One could go on a tangent about distributed version control
here, but let's pass it for now...)
> - Reduce release overhead (automate everything)
There are four parts to the process of making a releases:
1) Prepare for the release (schedule/fix issues, test, branch/tag when
ready etc.)
2) Package/build the release
3) Review/vote on the release
4) Publish the release
We can further automate parts 2 and 4, but they are already now
reasonably straightforward and by far the most overhead to making a
release comes from parts 1 and 3 that can't really be automated.
> - Release every 2 weeks
Then what's the difference between a release and an svn checkout? IMHO
we should only make feature release whenever we reach a reasonably
stable state for the new features and improvements. This will likely
always take longer than 2 weeks for any non-trivial enhancements. We
can certainly do patch releases more often.
> - No branches
What about production environments where you just want bug fixes to a
well tested base release instead of code from the bleeding edge?
There's certainly a need for maintenance release, and IMHO the best
way to manage them is with maintenance branches.
> - Only one jar file (unless it bigger than 2 MB)
What about people that just want to depend on our tools that work on
top of the JCR API? Should they be required to pull in all of
Jackrabbit as a dependency even if they work against some other
repository? A single release artifact also doesn't solve the api
versioning issue raised by Felix.
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I know this is radical, anyway:
- Add a lot of tests (functional coverage 100%, code coverage >90%)
- Only check in fully tested features (or mark them as "beta")
- Reduce release overhead (automate everything)
- Release every 2 weeks
- No branches
- Only one jar file (unless it bigger than 2 MB)
Regards,
Thomas
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 13, 2008 4:02 PM, Roland Weber <os...@dubioso.net> wrote:
> You'll have to use separate JIRA projects.
Agreed, that's the cleanest solution.
> > Either way we'll end up with problems if we have an issue that
> > affects more than one component at a time.
>
> You'll create separate issues and link them. Either as subtasks,
> or "depends on" or "blocks". Plenty of options there.
Yep. My main concern is that we'd add quite a bit of procedural
overhead since quite a few of our current issues affect more than one
component. I guess that with a sensible grouping of components (see
below) we could keep that overhead manageable.
> However, I strongly suggest that you don't put 22 artifacts on
> separate release cycles.
+1
> I recommend to shoot for a manageable 5 or 6 independent
> release cycles.
How about the following seven subproject groupings:
JCRAPI
jackrabbit-api
JCRSPI
jackrabbit-spi
JCR (the current Jira project)
jackrabbit-core
jackrabbit-jcr-commons
jackrabbit-spi-commons
jackrabbit-jcr2spi
jackrabbit-spi2jcr
jackrabbit-classloader
jackrabbit-text-extractors
jackrabbit-jcr-tests
(Note that core and the SPI implementation components are already
somewhat related, and should become more and more integrated as we go
forward, so splitting them to separate subprojects doesn't sound good
to me at this point.)
JCRRMI
jackrabbit-jcr-rmi
JCROCM
jackrabbit-ocm
jackrabbit-ocm-nodemanagement
JCRWEB
jackrabbit-jcr-server
jackrabbit-jcr-servlet
jackrabbit-webapp
jackrabbit-webdav
JCRJCA
jackrabbit-jca
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 13.01.2008, 15:02 +0100 schrieb Roland Weber:
> However, I strongly suggest that you don't put 22 artifacts on
> separate release cycles.
Definitely agree here :-)
> Every release comes with some overhead
> in preparing release notes, reviewing the artifacts, voting on
> the release, performing the release, sending the release mail,
> and updating the web page. That may not seem much while you're
> dealing with one release for all artifacts, but if you multiply
> that overhead twentyfold, you'll feel the pain. It will also
> get you and your users into dependency hell. Felix should be
> able to tell you a story or two about that from Apache Felix.
> IIRC, the next release of the maven-bundle-plugin depends on
> several other releases that have to be done first.
Well, I agree that the maven-bundle-plugin is a dependency hell. But
this is just one project and probably the one with the most
dependencies.
In addition, it is only the first time that we have much overhead. Later
on there will be less. Of course, we are in a better position in Felix
as we have the OSGi API which is pretty stable and have projects which
are more or less independent on each other.
> I recommend
> to shoot for a manageable 5 or 6 independent release cycles.
+1
Regards
Felix
> Without knowing the internals of Jackrabbit, for example:
> - base/common/util classes used almost everywhere
> - repository API and SPI
> - repository implementation(s)
> - remoting
> - WebDAV
> - ?
> I hope you get the idea. I know that the WebDAV component
> itself has a base, client and server section. Likewise, the
> remoting stuff surely has a client and a server section.
> But releasing one without the other is not likely, right?
> Splitting the code into components and packaging it into
> separate JARs is still possible if they are on the same
> release cycle. That's what JIRA components are good for.
>
> cheers,
> Roland
>
> [1] http://www.apache.org/dev/project-creation-tasks.html
>
Re: Smaller and Quicker Releases
Posted by Roland Weber <os...@dubioso.net>.
Hi folks,
Jukka wrote:
> The main problem I see with going with component releases is that
> using Jira for release management becomes a bit tricky. So far the
> "Fix version" tags in Jira have been one of my key tools in tracking
> which issues go into which release. To solve that we could either
> split JCR into multiple separate Jira projects, or use the component
> tags to scope the release numbers.
You'll have to use separate JIRA projects. Versions are not scoped
per component, and you can only change between "unreleased", "released",
and "archived" on the version level. Infra is aware of this and grants
you a JIRA project for each separately releasable package [1].
As an added bonus, you'll see in the subject of the JIRA mails
to which JIRA project they belong.
> Either way we'll end up with problems if we have an issue that
> affects more than one component at a time.
You'll create separate issues and link them. Either as subtasks,
or "depends on" or "blocks". Plenty of options there.
However, I strongly suggest that you don't put 22 artifacts on
separate release cycles. Every release comes with some overhead
in preparing release notes, reviewing the artifacts, voting on
the release, performing the release, sending the release mail,
and updating the web page. That may not seem much while you're
dealing with one release for all artifacts, but if you multiply
that overhead twentyfold, you'll feel the pain. It will also
get you and your users into dependency hell. Felix should be
able to tell you a story or two about that from Apache Felix.
IIRC, the next release of the maven-bundle-plugin depends on
several other releases that have to be done first. I recommend
to shoot for a manageable 5 or 6 independent release cycles.
Without knowing the internals of Jackrabbit, for example:
- base/common/util classes used almost everywhere
- repository API and SPI
- repository implementation(s)
- remoting
- WebDAV
- ?
I hope you get the idea. I know that the WebDAV component
itself has a base, client and server section. Likewise, the
remoting stuff surely has a client and a server section.
But releasing one without the other is not likely, right?
Splitting the code into components and packaging it into
separate JARs is still possible if they are on the same
release cycle. That's what JIRA components are good for.
cheers,
Roland
[1] http://www.apache.org/dev/project-creation-tasks.html
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 14.01.2008, 11:41 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 14, 2008 10:19 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > Well, the best solution to minimizing cross-component boundaries is to
> > clearly define interfaces and to abide by those :-)
>
> Agreed, but first we need to get there. I want the codebase structure
> to set the organizational boundaries, not the other way around.
So, let's just get going :-)
Regards
Felix
>
> > That's exactly the point I am trying to pin down: "synchronized
> > releases". This does not work out any more, so we should not try to do
> > it.
>
> ACK. The intermediate proposal was meant mainly as a temporary
> solution for Jackrabbit 1.4.x (and perhaps 1.3.x) if we can't come up
> with a more complete subproject structure before we need to start
> putting out patch releases. The idea would also still work within the
> proposed subproject groups, in cases where we need to make patch
> releases of individual components.
>
> BR,
>
> Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 14, 2008 10:19 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Well, the best solution to minimizing cross-component boundaries is to
> clearly define interfaces and to abide by those :-)
Agreed, but first we need to get there. I want the codebase structure
to set the organizational boundaries, not the other way around.
> That's exactly the point I am trying to pin down: "synchronized
> releases". This does not work out any more, so we should not try to do
> it.
ACK. The intermediate proposal was meant mainly as a temporary
solution for Jackrabbit 1.4.x (and perhaps 1.3.x) if we can't come up
with a more complete subproject structure before we need to start
putting out patch releases. The idea would also still work within the
proposed subproject groups, in cases where we need to make patch
releases of individual components.
BR,
Jukka Zitting
Re: Smaller and Quicker Releases
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 11.01.2008, 17:25 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 11, 2008 4:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > * We stop making big releases as we do now
> > * We release as appropriate and as required
>
> +1 Agreed.
>
> I was originally thinking about making the switch to component
> releases only after Jackrabbit 2.0, but it seems like we need to do at
> least something along those lines already now. Our codebase is already
> pretty huge and almost all parts of it are being actively developed.
> Managing a release with 220 resolved issues (most of them new features
> or improvements since bug fixes have already gone out in 1.3.x
> releases...) has been somewhat challenging. :-)
>
> I guess we really should have made 1.4 already earlier and had this
> release be already 1.5 to lessen the amount of changes, but that
> doesn't resolve the other points you raised.
Correct. It does not matter whether we would have done 1.4 sooner or
later. The problems remain the same :-)
>
> The main problem I see with going with component releases is that
> using Jira for release management becomes a bit tricky. So far the
> "Fix version" tags in Jira have been one of my key tools in tracking
> which issues go into which release. To solve that we could either
> split JCR into multiple separate Jira projects, or use the component
> tags to scope the release numbers. Either way we'll end up with
> problems if we have an issue that affects more than one component at a
> time.
>
> One could argue that we shouldn't have cross-component issues, and
> that we should first change one component in the context of one issue
> and only then make related changes to another component with another
> issue that depends on the first one. I don't think we are too far
> ahead in componentization to make that work seamlessly, but I guess
> forcing such boundaries organizationally might also help the codebase
> structure.
Well, the best solution to minimizing cross-component boundaries is to
clearly define interfaces and to abide by those :-)
Nevertheless, there may now and then come up such issues and we will
have to cope with them. But I think the cost of these - hopefully -
seldom issues is much less than the cost of cutting a release as we do
now.
>
> > This results in more releases but in a much faster release turnaround.
> > So for example to make an urgent release with the OCM component (just an
> > example), we would not have to wait for any other component being ready
> > for release. We just fix and release.
>
> Note that there's no stopping us doing such point releases even now if
> we want to, they just need to be managed outside the normal release
> cycle (something like jackrabbit-ocm-1.4.0.1).
Sure. What I questio is the "normal release cycle" you mention: I think
we should replace it with something more suitable.
>
> There's also an intermediate solution that I was actually planning to
> propose for post-1.4. We could use the current synchronized releases
> only for 1.x minor releases, and make all 1.x.y patch releases be
> component-based. The bug fixes that go in patch releases are typically
> much more tightly scoped and don't cross component boundaries so the
> above-mentioned problems would not be that big.
That's exactly the point I am trying to pin down: "synchronized
releases". This does not work out any more, so we should not try to do
it.
>
> With this idea the release schedule could be something like this:
>
> jackrabbit-1.4
> jackrabbit-core-1.4.1
> jackrabbit-ocm-1.4.1
> jackrabbit-core-1.4.2
> jackrabbit-jcr-rmi-1.4.1
> jackrabbit-core-1.4.3
> jackrabbit-ocm-1.4.2
> jackrabbit-1.5
> ...
Agreed with an important note: The jackrabbit-x.y release should NOT
force release numbers onto its constituents. Just because there is a
huge (or at least big) Jackrabbit x.y release, not every part of the
release must be versioned as x.y. This makes migration needless
complicated as it implies a requirement to an all-or-nothing migration,
which is not a valid value proposition, I think.
I rather see the Jackrabbit x.y releases as precanned collection of
already existing releases. Its just a packaging of those, nothing new.
>
> > And even better: I am sure, we might even be able to prevent creating
> > branches :-)
>
> -1 With branches we can always keep the trunk free for other changes
> than just bug fixes. Without a branch you always need to consider
> whether it's OK to start for example some refactoring work or whether
> we need to release previous bug fixes first. With maintenance branches
> we can easily keep the patch releases tightly scoped to contain only
> bug fixes. Backporting issues is some pain, but I think it's well
> worth it.
Now, if we do finer releases, and the Jackrabbit x.y releases are
nothing new but just repackagings, what would you branch ? Each
component on release ?
I would rather turn it around: If you want to work on a functionality
contains big refactorings, you may branch off and work on the branch or
you may use the sandbox. This second solution is how we do it over in
Apache Felix.
It hink this approach is much less intrusive as it places the burden
solely on the developer of the big refactoring and leaves the others
alone up to the point, where the refactoring is decided to be merged
into the trunk.
Regards
Felix
Re: Smaller and Quicker Releases
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 11, 2008 4:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> * We stop making big releases as we do now
> * We release as appropriate and as required
+1 Agreed.
I was originally thinking about making the switch to component
releases only after Jackrabbit 2.0, but it seems like we need to do at
least something along those lines already now. Our codebase is already
pretty huge and almost all parts of it are being actively developed.
Managing a release with 220 resolved issues (most of them new features
or improvements since bug fixes have already gone out in 1.3.x
releases...) has been somewhat challenging. :-)
I guess we really should have made 1.4 already earlier and had this
release be already 1.5 to lessen the amount of changes, but that
doesn't resolve the other points you raised.
The main problem I see with going with component releases is that
using Jira for release management becomes a bit tricky. So far the
"Fix version" tags in Jira have been one of my key tools in tracking
which issues go into which release. To solve that we could either
split JCR into multiple separate Jira projects, or use the component
tags to scope the release numbers. Either way we'll end up with
problems if we have an issue that affects more than one component at a
time.
One could argue that we shouldn't have cross-component issues, and
that we should first change one component in the context of one issue
and only then make related changes to another component with another
issue that depends on the first one. I don't think we are too far
ahead in componentization to make that work seamlessly, but I guess
forcing such boundaries organizationally might also help the codebase
structure.
> This results in more releases but in a much faster release turnaround.
> So for example to make an urgent release with the OCM component (just an
> example), we would not have to wait for any other component being ready
> for release. We just fix and release.
Note that there's no stopping us doing such point releases even now if
we want to, they just need to be managed outside the normal release
cycle (something like jackrabbit-ocm-1.4.0.1).
There's also an intermediate solution that I was actually planning to
propose for post-1.4. We could use the current synchronized releases
only for 1.x minor releases, and make all 1.x.y patch releases be
component-based. The bug fixes that go in patch releases are typically
much more tightly scoped and don't cross component boundaries so the
above-mentioned problems would not be that big.
With this idea the release schedule could be something like this:
jackrabbit-1.4
jackrabbit-core-1.4.1
jackrabbit-ocm-1.4.1
jackrabbit-core-1.4.2
jackrabbit-jcr-rmi-1.4.1
jackrabbit-core-1.4.3
jackrabbit-ocm-1.4.2
jackrabbit-1.5
...
> And even better: I am sure, we might even be able to prevent creating
> branches :-)
-1 With branches we can always keep the trunk free for other changes
than just bug fixes. Without a branch you always need to consider
whether it's OK to start for example some refactoring work or whether
we need to release previous bug fixes first. With maintenance branches
we can easily keep the patch releases tightly scoped to contain only
bug fixes. Backporting issues is some pain, but I think it's well
worth it.
BR,
Jukka Zitting