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, or do you go with version 1.1 to match, or do you not even bother updating and expect the user to update the version of its transitive dependency?
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 > > -- Matt Sicker <boa...@gmail.com>
