commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [ALL] Version number(s) for modular components
Date Sat, 26 Nov 2016 16:20:14 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message