On Sun, 27 Nov 2016 20:35:51 -0600, Matt Sicker wrote:
Here's an example of a confusing versioning situation:
1. commons-foo-base version 1.1 is released
2. commons-foo-utils is still at version 1.0 as no code was updated.
Do you
release a 1.0.1 with a dependency update on commons-foo-base 1.1,
No.
Case 1:
IF
"commons-foo-utils" can benefit from the newer "commons-foo-base"
AND
the development team has the time to make the necessary updates to
"commons-foo-utils" (i.e. updating it will not unduly delay the
release of "commons-foo-base")
THEN
"commons-foo-utils" 1.1 is released (add 1 to the "minor" version
number, not to the "bug-fix" version number) with a dependency to
"commons-foo-base" 1.1
Case 2:
IF
"commons-foo-utils" does not use any of the new features in
"commons-foo-base" 1.1
THEN
there is no new release of "commons-foo-utils"
Advantage (as noted earlier): a user who only uses "commons-foo-utils"
need not worry about upgrading its dependency (while in the "simple"
scheme, he has to, e.g. before he can report bugs).
or do you
go with version 1.1 to match,
There is nothing try and match; cf. my original post:
---QUOTE---
[It should be clear that having the same version numbers for
"foo" and "bar" would be a pure coincidence.]
---QUOTE---
or do you not even bother updating
and expect the user to update the version of its transitive
dependency?
No.
IF
there was no change in the version number of "commons-foo-utils"
THEN
there was no change in the dependencies of "commons-foo-utils"
The development cycles of the modules within a component are
potentially completely independent.[1]
In the same way that the development cycle of "Commons" components
is independent,
In the same way that the development cycle of non-"Commons" projects
is independent.
In the same way that the development cycle of the JDK is independent.
In the same way that the development cycle of the OS is independent.
Etc.
One module can decide to upgrade, or not, depending on the available
resources.
In your example, the release of "commons-foo-utils" 1.1 can happen
months after the release of "commons-foo-base" 1.1.
[It could even be so that a "commons-foo-base" 1.2 was released in
int the mean time, and then "commons-foo-utils" 1.1 would likely
depend on "commons-foo-base" 1.2.]
Regards,
Gilles
[1] Even if, in practice, we'd tend to make as many simultaneous
releases, to minimize the number of [VOTE] posts.
On 27 November 2016 at 18:12, Gilles <gil...@harfang.homelinux.org>
wrote:
[...]
<IMO>
Let's keep in mind the context here: This is a component in Apache
Commons,
not a TLP. Therefore, IMO, we should match user's expectations of
simplicity, which is one repo and version for the component,
multi-module
or not, just like all of the other Apache Commons components, where
all
Commons multi-module components are released as one version.
</IMO>
So, the issue is not to try and decide whether an idea is good or
bad,
but to follow a rule that is deemed "simple".[1]
The problem is that this rule is not one, since I gave a
counter-example
with "Commons Math".
If such "Commons" policies (good or bad) would be documented and
_enforced_,[2] much less discussion would ensue.
And more people might become aware of the contradictions brought
along
with the set of rules they qualify as "simple" when a project does
not
fit their a priori conceptions.
Gilles
[1] And nothing that has been said is a convincing argument that a
single version number, for a bunch of weakly related codes,
better
qualify as "simple" rather than "misleading".
[2] Branch "MATH_3_X" of "Commons Math" would either have been
vetoed
or the rule which you advocate here (one version per repo) would
have been repealed, years ago.
It is such contradictions that make it very difficult to go
forward
in "Commons".
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
