Ordering of versions

[Brian Pontarelli]

I'm actually not a huge advocate for multiple version schemes, but I think it is still possible to define well-known version schemes and version them via a module (or other external version concept).

However, I still think that the EBNF I sent out (or something similar) is going to cover most cases. I also feel like those that have internal version schemes that don't fit can switch since they will have to change up a lot more than just the version scheme to start using modules.

-bp


On Nov 14, 2011, at 9:15 AM, Neil Bartlett wrote:

> Brian,
> 
> You're right that a module need not be compared against other modules
> for versioning purposes. But for this idea to work, each module would
> have to provide its own implementation of a Version class, which has a
> number of very challenging implications. First, where would that class
> be loaded from?
> 
> It could not be loaded from the module itself because it is needed at
> build, install and resolve time, i.e. well before any class from the
> module could possibly be executed. So it would have to be loaded via
> some means external to or alongside the module system. Then how would
> the implementation of the Version itself be evolved? Suppose I found a
> bug in my compareTo() method, how would I provide a fix to the bug?
> Potentially each version of a module would end up with its own version
> *scheme*, which would be nonsense.
> 
> The whole idea reminds me of the "module resolution scripts" that were
> suggested back in the days of JSR 277. They would have been a disaster
> as well, not least because they would have made it impossible to
> statically reason about the dependency graph.
> 
> So, I don't think any reasonable module system can allow each module
> to decide version *ordering* arbitrarily. There has to be one ordering
> rule used by all modules. I would also like there to be one set of
> semantics for version bumps in each segment... but I can see that the
> chances of getting that in the Java 8 Module System are currently
> slim.
> 
> Regards,
> Neil
> 
> On Mon, Nov 14, 2011 at 4:04 PM, Brian Pontarelli <brian at pontarelli.com> wrote:
>> It seems to me that the version scheme for a single module only impacts that module and not its dependencies. When the dependency graph is completely built and then traversed, modules are compared based on their scheme with all the other instances of themselves in the graph. Therefore, I don't think it impacts others at all.
>> 
>> Thoughts?
>> 
>> -bp
>> 
>> 
>> On Nov 14, 2011, at 7:49 AM, Peter Kriens wrote:
>> 
>>> Gili,
>>> Can you explain how this would work when my modules use a different scheme than yours?
>>> 
>>> Kind regards,
>>> 
>>>       Peter Kriens
>>> 
>>> On 13 nov. 2011, at 04:59, cowwoc wrote:
>>> 
>>>> 
>>>> mark.reinhold wrote:
>>>>> 
>>>>> Support such semantics, sure, but I'm not sure it should prescribe them.
>>>>> OSGi and Maven have established some useful and widely-used conventions
>>>>> around version semantics but I've seen developers and customers use all
>>>>> sorts of other wild and woolly version schemes over the years.  I'm not
>>>>> convinced that a standard Java module system should require people to
>>>>> abandon such schemes, unless they're just really totally broken.
>>>>> 
>>>> 
>>>> Mark,
>>>> 
>>>> If at all possible, please consider allowing users to specify a
>>>> Comparator<Version> (or Comparator<String> depending on your taste) on a
>>>> per-module basis. This would allow users to use any versioning scheme they
>>>> see fit.
>>>> 
>>>> Gili
>>>> 
>>>> --
>>>> View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Ordering-of-versions-tp4970773p4988030.html
>>>> Sent from the jigsaw-dev mailing list archive at Nabble.com.
>>> 
>> 
>>