Hello.
As a follow-up of
http://markmail.org/message/jckbknphndecglns
and
http://markmail.org/message/f3g33kvevf52xohf
I summarize what I think should be allowed for versioning
modularized components of the "Commons" project.
Assume there are two modules in project "Commons ModProj":
commons-modproj-foo
commons-modproj-bar
Their respective "top-level package" would be:
org.apache.commons.modproj.foo
org.apache.commons.modproj.bar
I propose that versioning of the modules are independent
(as if they were different components).
As said in the referred posts, it would allow the version
numbers to reflect the actual state of each of the module.
For example, assume that this proposal is validated, and
that
commons-modproj-foo-1.0
commons-modproj-bar-1.1
were released.
Note: for the sake of exercising the version changes, all the
cases below happen in the sequence shown (ala "switch" with
"case" without "break").
=== Case (A) ===
We must release a non-BC upgrade of "bar".
Hence, we would release
commons-modproj-bar-2.0
with "top-level package"
org.apache.commons.modproj.bar2
Advantage: applications that only use module "foo" are unaffected.
=== Case (B) ===
Assume that "bar" depends on "foo".
-- Case (B1) --
We release a BC version of "foo":
commons-modproj-foo-1.1
* Case (B1+)
The upgrade consists of new features only.
Module "bar" is totally unaffected (what worked with foo-1.0
works the same with foo-1.1) and no new release of "bar2"
will happen.
Advantage: users of "bar2" only will not wonder whether they
should upgrade (if they did not intend to use new features,
there is no reason for them to upgrade).
* Case (B1-)
The upgrade consists of bug fixes.
Both modules will be released, i.e.
commons-modproj-foo-1.1.1
commons-modproj-bar2-2.0.1
This will trigger an upgrade for all users (who care about
correctness).
-- Case (B2) --
We release a non-BC version of "foo":
commons-modproj-foo2-2.0
with "top-level package"
org.apache.commons.modproj.foo2
* Case (B2+)
The upgrade is purely a re-design.
The development team is free to (major) release the new
"foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
(2.0.1) still uses "foo-1.1.1".
~ Case (B2+sync)
Team is able to provide, at time of release, a bridge and
release
commons-modproj-bar2-2.1
so that users of "bar2-2.1" will transparently use
"foo2-2.0"
(in place of "foo-1.1.1").
~ Case (B2+async)
Team is able to provide (or improve) the bridge later on,
i.e. release
commons-modproj-foo2-2.1
commons-modproj-bar2-2.2
so that users of "bar2" only will transparently use
"foo2-2.1"
(in place of "foo-1.1.1" or "foo2-2.0").
Advantages:
- Redesigned "foo" can be released without worrying about
upgrading "bar" (RERO).
- Users of "bar2" only can either not worry about upgrade,
or just update their version dependency (not changing a
single line of code).
* Case (B2++)
Previous re-design turned out to be sub-optimal.
A new major "foo" is released:
commons-modproj-foo3-3.0
with "top-level package"
org.apache.commons.modproj.foo3
[Same (non-)consequences for "bar2" as previous case.]
* Case (B2-)
An upgrade also contains bug-fixes.
A new major "foo" will be released, i.e.
commons-modproj-foo4-4.0
with "top-level package"
org.apache.commons.modproj.foo4
together with a new major "bar"
commons-modproj-bar3-3.0
with "top-level package"
org.apache.commons.modproj.bar3
Here the upgrade of "bar" will force its users to think
about whether they need to upgrade (whether they are
impacted by the bugs or they want to have support usually
provided for latest version only).
=== Case (C) ===
People want to completely redesign the whole "ModProj" functionality.
We can release
commons-modproj2-foo-1.0
commons-modproj2-bar-1.0
Their respective "top-level package" would be:
org.apache.commons.modproj2.foo
org.apache.commons.modproj2.bar
At this point we'd have these modules officially released:
commons-modproj-foo4-4.0
commons-modproj-bar3-3.0
commons-modproj2-foo-1.0
commons-modproj2-bar-1.0
all happily living together[1]; and improvements can be easily
exchanged among the different lines of development (e.g. via
"git" branches).
Obviously, the significant change is that version numbers are
tied to modules, not component. Does that pose a problem?[2]
[It should be clear that having the same version numbers for
"foo" and "bar" would be a pure coincidence.]
In particular, version and package changes are confined to
where code changes happen; they follow the development of
specific features (while non-impacted code is not forced to
adopt a version that is actually related to "foreign" code).
Another fundamental advantage, community-wise, is that it is
conducive to maintaining a good relationship among developers
even if they want to "scratch different itches".[3]
In effet, this scheme would allow to group codes by "broad"
subject while module management could be fine-grained,[4]
up to using specific version suffixes (such as "-dev" or
"-extras") to convey intended use or audience or level of
support...
Regards,
Gilles
[1] Provided the dependencies are correct of course.
[2] According to Stian, it does not (IIRC).
[3] Whereas the current scheme turned different POV into personal
fights, with punctual winners and losers (however gracefully
they think they can handle it) but an enduring overall loss
for the community.
[4] On a par with the varying levels of development (for whatever
reasons, such as lack of time or lack of contributors) of those
modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
