Hi Jukka,
Thanks for your thoughts on this issue. Please find my comments inline.
Jukka Zitting schrieb:
Hi,
As far as I've understood, the plan going forward is to have separate
release cycles for all Sling components. Does this mean that each
component would get their own trunk,branches,tags structure, or do we
still keep everything inside a single trunk and perhaps use
subdirectories within the existing branches and tags directories?
First off: No Branches here ;-) [ unless really required, of course ]
Second: We have a single trunk. For each release we create a tag in the
single tags folder we have. If we discover, that we get too many tags in
the single tag folder, we might start creating subfolders in the tags
folder (I would say along the lines of the structure in the trunk).
How will inter-component dependencies be managed? Currently many
components in the trunk depend on the released 2.0.2 versions, so you
end up with a bit confusing setup where the build generates one
version of one component but downloads another version as a dependency
for another component. Perhaps that's jst OK.
Basically, each component should refer to the minimum version required
of any other component and it should refer to a released version of said
component. Of course, if there is a dependency on an unreleased feature
-- e.g. the jcr/resource project implementing new unreleased API of the
api project -- a SNAPSHOT dependency is ok until release.
This ensures the maven bundle plugin will create correct version tags
for the Import-Package headers.
In addition, for all exported packages/classes, we will have to take
care to be backwards compatible, of course.
Versions of components are _not_ synchronized by intent. Just as we do
not synchronize with any external component we depend on. This
synchronization is not possible and not desired. All actual runtime
dependencies are declared in the Import-Package headers.
Do we have the release management capacity to manage dozens of
separate release cycles? I mean, even if we did just a single release
per year for a component, we'd still be releasing stuff almost weekly.
I do not envision weekly releases of single components. But there may
well be one or two releases (or more) per month, yes. We also have this
over at Felix and it works quite well.
The point in this is, that we automate as much as possible and that
there is not a single release manager. It is rather the case, that
people requiring a release generally cut the release and conduct the
complete procedure. We might codify this further by requiring such a
process to be always lead by a (P)PMC member.
To simplify things, would it make sense to make the components more
coarse-grained? For example, would it be bad to merge all the commons
components into a single utility component?
I would only consider merging if it would make sense on a code-wise
basis. Merging to "simplify" release management is IMHO wrong and bad.
Because in the end we might have to cut a release of a component due to
a single contained part but another part of the component may not be
ready for release yet and we end up in a real mess.
Also, do all the components need to be bundles or would it make more
sense for them to be normal jars that bundles that require that
functionality just embed? The way I see it (and I may well be wrong)
is for bundles to be used for coarse grained and loosely coupled
services. I for example don't see why the commons/json component
should be a separate bundle and not an internal dependency of whatever
bundle that requires JSON functionality.
Good point. I think this question cannot be answered once and for all.
It needs to be decided on a case-by-case basis. After all, it is a
decision of the bundle creater/maintainer which mechanism to use.
Basically, some bundles may just provide services and other bundles may
provide library functionality and still other bundles may just provide
API. As soon as two bundles need to share data, they need to share the
types of the data. This may not be a big issue for JSON but may be a
bigger issue for others. YMMV, as always.
In the end, we should make everything a bundle. This enables all use
cases, import and embedding. Because, remember: A bundle basically is
just a JAR with special manifest headers.
Hope this helps.
After all, it may probably be a good thing to start a wiki page on these
issues to come up with some kind of release concept to which people may
refer in case of uncertainties.
Regards
Felix
