Use-cases for version ranges?

cowwoc cowwoc at bbs.darktech.org
Mon Nov 21 12:16:39 PST 2011 

     The reason I advocate placing the meta-data outside of the module 
is that people make mistakes. What happens if you specify a version 
range that turns out to be incorrect? You need to be able to fix these 
kinds of things after the fact.

Gili

On 21/11/2011 3:11 PM, David Bosschaert [via jigsaw-dev] wrote:
> I think that the fact that in JBoss Modules the metadata is *outside*
> of the module (in a separate file that sits alongside the module) and
> in OSGi the metadata is *inside* the module (embedded in the Jar) is a
> significant difference.
>
> If you have the metadata outside of the module you have additional
> flexibility. You can change the metadata without changing the module
> itself, so if there is an issue with the metadata you can easily fix
> it up (e.g. if you need to depend on another version of your
> dependency). Also there are obviously impacts of changing the module
> metadata if its inside the module and you are working with signed
> jars. On the other side, having the metadata inside the module has the
> benefit that you only need to worry about a single artifact: the
> module itself.
>
> I'm not advocating one over the other here; I think both have
> benefits, but I think that using version ranges makes more sense in
> the case the metadata is embedded in the module.
>
> If I'm not mistaken, the model that Jigsaw is going for is currently
> also the model where the metadata is inside the module.
>
> David
>
> On 21 November 2011 16:33, David M. Lloyd <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011534&i=0>> wrote:
>
> > On 11/21/2011 10:11 AM, Neil Bartlett wrote:
> >>
> >> David,
> >> I'm likewise tired of hearing these defeatist straw-man arguments.
> >> First, nobody is suggesting that you be forced to use version ranges.
> >> Second, nobody is suggesting that you be forced to design software by
> >> separating interfaces from implementation. Finally, nobody is
> >> suggesting that unmodified legacy code can be trivially modularised in
> >> *any* module system.
> >
> > Trivial?  Depends on how you define it.  Most artifacts should be 
> able to be
> > modularized as-is however, with minimal changes if any.  We adopted an
> > external descriptor strategy for the sole purpose of being able to use
> > modules as is, and we were able to package our 200+ modules just 
> that way,
> > no repackaging needed.  So far the only problems we have really run 
> into
> > seem to be legitimate bugs, and one or two libraries which assume a 
> flat
> > classpath.
> >
> > I just glanced at the quick stats for Maven Central.  There are 267,924
> > indexed artifacts at the time of this writing - 31,847 unique 
> artifacts.
> >  This is a major reason why people even use Java in the first place. 
> Ideally
> > we would be able to start with at least the possibility of having a 
> somewhat
> > pre-populated repository.
> >
> >> The module system must support both existing software and new
> >> software, of course. You seem suggest that I believe existing software
> >> is unimportant; nothing could be further from the truth. But I also
> >> believe that new software is important and that practices like
> >> interface/implementation separation and semantic versioning will help
> >> make the new software better than the old software.
> >> Therefore I believe that these features must be supported (though not
> >> mandated) in any new module system. You appear to be suggesting that
> >> these features are worthless because they cannot be applied to
> >> existing software, and/or will not be used by all Java developers.
> >> Well so what??
> >
> > Not worthless, but a question of personal choice.  I believe that 
> interface
> > and implementation separation has not been objectively shown to be a
> > superior way to write frameworks.  In my experience, sometimes it is 
> and
> > sometimes it is not.
> >
> > I believe that "semantic versioning" isn't going to work because 
> most people
> > who develop Java software will not understand it or not get it 
> right, due in
> > no small part to being a complex idea with a lot of subtlety.  In 
> think that
> > empirical testing is the only way to ensure compatibility which will 
> scale.
> >
> >> Regards,Neil
> >> On Mon, Nov 21, 2011 at 3:15 PM, David M. Lloyd<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011534&i=1>>
> >>  wrote:
> >>>
> >>> I'm tired of hearing pie-in-the sky, "intro to OOP" wishful crap like
> >>> this.
> >>>  Mission one should be supporting *existing* code.  The fact is that
> >>> people
> >>> do *not* always split their API from their implementation, and APIs
> >>> almost
> >>> *never* consist solely of interfaces.  There are many ways of 
> designing
> >>> an
> >>> API which people consider "right" and I don't see anyone on this list
> >>> having
> >>> any special insight that would enable them to select the "one true"
> >>> approach
> >>> to API design.
> >>>
> >>> The fact is that any version scheme or module resolution engine which
> >>> only
> >>> works for new code which is designed "properly" for it is *going* to
> >>> fail.
> >>>  And there's no reason for such constraints anyway.  Version 
> ranges are
> >>> barely useful at all in practice.  The only ones who can assert
> >>> compatibility between two libraries of arbitrary version are the 
> ones who
> >>> have tested the two together (along with anything else that uses a
> >>> combination of the two).
> >>>
> >>> The best one can do establish *minimum* compatibility based on 
> available
> >>> features, and test test test.  When a module is added to a 
> repository, if
> >>> it
> >>> is tested by running both its internal unit tests and all 
> available tests
> >>> of
> >>> all its dependents, then that should be adequate to establish
> >>> compatibility
> >>> *within a repository*.  There are too many factors to establish
> >>> compatibility beyond it.
> >>>
> >>> On 11/20/2011 07:45 AM, Neil Bartlett wrote:
> >>>>
> >>>> Stephen,
> >>>>
> >>>> You again seem to be talking about dependencies on implementation
> >>>> packages. If we depend on APIs consisting primarily of interfaces,
> >>>> then versions and version ranges are reliable and can be completely
> >>>> automated.
> >>>>
> >>>> Regards,
> >>>> Neil
> >>>>
> >>>>
> >>>> On Sun, Nov 20, 2011 at 12:25 PM, Stephen McConnell<[hidden 
> email] </user/SendEmail.jtp?type=node&node=5011534&i=2>>
> >>>>  wrote:
> >>>>>
> >>>>> I could say that the question is academic - but here is the 
> thing - its
> >>>>> not
> >>>>> even academic.
> >>>>>
> >>>>> We talk about versions and yet the platform has no computational
> >>>>> mechanisms
> >>>>> to flag version violation. At least an academic discussion would 
> bring
> >>>>> in
> >>>>> grounded metrics.  In reality - the discussion here about V1 
> versus V2
> >>>>> and
> >>>>> that warm fuzzy feeling when your are just a n.m from an n+1 and 
> it's a
> >>>>> waste of breath (and that comment goes to all sides of the debate).
> >>>>>
> >>>>> Give me an endorsed tool that shows me that module 
> [name]-[build] is
> >>>>> computationally backward compatible to a different 
> [name]-[build] and
> >>>>> then,
> >>>>> only them will this discussion have reasonable grounds to assert 
> any
> >>>>> authority on the subject of version compatibility (past or future).
> >>>>> Without
> >>>>> that tool - versioning is a unqualified statement of trust. And the
> >>>>> evidence
> >>>>> suggests that the threshold of trust delivery on actual 
> computational
> >>>>> compliance is really really thin.
> >>>>>
> >>>>> Cheers, Steve.
> >>>>>
> >>>>>
> >>>>> -----Original Message----- From: cowwoc
> >>>>> Sent: Sunday, November 20, 2011 1:39 PM
> >>>>> To: [hidden email] </user/SendEmail.jtp?type=node&node=5011534&i=3>
> >>>>> Subject: Re: Use-cases for version ranges?
> >>>>>
> >>>>>
> >>>>>    I'd like to propose another possibility: the author of the
> >>>>> dependency should tell *us* about version compatibility, not the 
> other
> >>>>> way around. For example:
> >>>>>
> >>>>> 1. The author of module A declares a dependency on module B 
> version 1.2
> >>>>> (specific version).
> >>>>> 2. The author of module B publishes version 1.3. He declares that
> >>>>> version 1.3 is compatible with 1.2 (meaning, the runtime system is
> >>>>> allows to substitute version 1.3 for 1.2).
> >>>>>
> >>>>>    The upside of this approach is that the author of B is in a 
> better
> >>>>> position to declare compatibility than the author of A. The 
> author of A
> >>>>> still only needs to test a single version. What do you think?
> >>>>>
> >>>>> Gili
> >>>>>
> >>>>> On 19/11/2011 1:59 AM, Neil Bartlett wrote:
> >>>>>>
> >>>>>> Gili,
> >>>>>>
> >>>>>> I didn't say anything about guarantees, and in this industry I 
> have
> >>>>>> never heard of anybody providing a guarantees about the 
> performance of
> >>>>>> their software, especially in the presence of external 
> dependencies.
> >>>>>>
> >>>>>> Version ranges are a means of communicating expectations, and we
> >>>>>> provide both a lower and an upper bound because this is useful
> >>>>>> information. I expect my module will work with 1.2.14, and I 
> expect it
> >>>>>> will not work with 2.0. If I were a provider of the API rather 
> than a
> >>>>>> consumer then I would have a much narrower expectation,  e.g.
> >>>>>> [1.2,1.3), and this would also be useful information to convey.
> >>>>>>
> >>>>>> Regards
> >>>>>> Neil
> >>>>>>
> >>>>>> On Sat, Nov 19, 2011 at 4:27 AM, cowwoc<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011534&i=4>>
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> Neil,
> >>>>>>>
> >>>>>>>    I guess I don't understand why Jigsaw should work 
> differently from
> >>>>>>> Maven
> >>>>>>> on this point. I am expecting developers to specify specific 
> versions
> >>>>>>> that
> >>>>>>> they tested (point versions, not ranges) and end-users may 
> override
> >>>>>>> these
> >>>>>>> "recommendations" as they see fit.
> >>>>>>>
> >>>>>>>    Where you see version range [1.2.14, 2.0) as a way of
> >>>>>>> communicating
> >>>>>>> "the
> >>>>>>> developer guarantees 1.2.14 but you may use newer versions up 
> to 2.0
> >>>>>>> at
> >>>>>>> your
> >>>>>>> own risk" I'd expect the developer to simply specify 1.2.14 
> and there
> >>>>>>> should
> >>>>>>> be no limit on what version end-users may use if they so wish.
> >>>>>>>
> >>>>>>> Gili
> >>>>>>>
> >>>>>>> On 18/11/2011 2:23 AM, Neil Bartlett wrote:
> >>>>>>>>
> >>>>>>>> I noticed that I failed to address your point about Maven using
> >>>>>>>> point
> >>>>>>>> versions.
> >>>>>>>>
> >>>>>>>> Maven is a build tool. At build time we need to compile 
> against a
> >>>>>>>> single specific version so that we have repeatable builds. In
> >>>>>>>> general
> >>>>>>>> we should build each module against the lowest version of the
> >>>>>>>> library
> >>>>>>>> that it can possibly use, and there are no major negative
> >>>>>>>> consequences
> >>>>>>>> of having several versions of a library at build time (except 
> that
> >>>>>>>> Maven has to download a lot!). At runtime however we need to 
> have
> >>>>>>>> the
> >>>>>>>> flexibility to substitute a single compatible version.
> >>>>>>>>
> >>>>>>>> Neil
> >>>>>>>>
> >>>>>>>> On Fri, Nov 18, 2011 at 7:10 AM, Neil Bartlett<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011534&i=5>>
> >>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>> Suppose as the developer of module A, I declare a dependency on
> >>>>>>>>> log4j,
> >>>>>>>>> exactly version 1.0.0 because I have not tested against log4j
> >>>>>>>>> 1.0.1,
> >>>>>>>>> 1.0.2, 1.3, 999.999 etc. I effectively prevent my module *ever*
> >>>>>>>>> being
> >>>>>>>>> used with log4j version 1.0.1 even if this combinations is 
> later
> >>>>>>>>> tested and proven to work by somebody else. In other words, 
> testing
> >>>>>>>>> is
> >>>>>>>>> important but it doesn't necessarily have to always be done 
> by the
> >>>>>>>>> original developer of each module.
> >>>>>>>>>
> >>>>>>>>> On the other hand let's say I state my dependency using the
> >>>>>>>>> following
> >>>>>>>>> range: [1.2.14, 2.0). This is OSGi syntax and I believe 
> Jigsaw is
> >>>>>>>>> following it, and it simply means I accept version 1.2.14 up 
> to but
> >>>>>>>>> not including 2.0. Anybody can see that I compiled and tested
> >>>>>>>>> against
> >>>>>>>>> 1.2.14, but has the option of using 1.2.15, 1.2.16, 1.3, 1.9 
> etc.
> >>>>>>>>> It
> >>>>>>>>> does not mean that I *guarantee* my module will work with 
> log4j 1.3
> >>>>>>>>> because that obviously depends on whether the log4j authors 
> accept
> >>>>>>>>> and
> >>>>>>>>> follow the common semantics of indicating 
> backwards-incompatible
> >>>>>>>>> changes with a bump to the first version segment.
> >>>>>>>>>
> >>>>>>>>> The consequence of trying to lock down imports to a narrow 
> range or
> >>>>>>>>> even a point version is that assembling an application 
> becomes very
> >>>>>>>>> difficult, and we are forced to deploy many versions of common
> >>>>>>>>> libraries concurrently. This is non-optimal, though we can 
> handle
> >>>>>>>>> it
> >>>>>>>>> to some degree via per-module classloaders as in OSGi.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Neil
> >>>>>>>>>
> >>>>>>>>> On Thu, Nov 17, 2011 at 11:52 PM, cowwoc<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011534&i=6>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Can someone please explain why modules need to be able to 
> specify
> >>>>>>>>>> version
> >>>>>>>>>> ranges for dependencies? I believe OSGI allows the 
> specification
> >>>>>>>>>> of
> >>>>>>>>>> version
> >>>>>>>>>> ranges while Maven allows the specification of individual
> >>>>>>>>>> versions.
> >>>>>>>>>>
> >>>>>>>>>> The only thing that comes to mind is when module C depends 
> on A
> >>>>>>>>>> and
> >>>>>>>>>> B,
> >>>>>>>>>> A
> >>>>>>>>>> depends on log4j 1.0, and B depends on log4j 1.1. What does 
> C do?
> >>>>>>>>>> Is
> >>>>>>>>>> this
> >>>>>>>>>> the main use-case for version ranges?
> >>>>>>>>>>
> >>>>>>>>>> By the sound of it, this is a trust model where developers are
> >>>>>>>>>> told
> >>>>>>>>>> that
> >>>>>>>>>> log4j 1.x won't break compatibility so they depend on that 
> range
> >>>>>>>>>> without
> >>>>>>>>>> actually testing against each version (newer versions may be
> >>>>>>>>>> released
> >>>>>>>>>> after
> >>>>>>>>>> their own software). I question whether such a mechanism is 
> better
> >>>>>>>>>> or
> >>>>>>>>>> worse
> >>>>>>>>>> than depending on individual versions which may be 
> overridden at a
> >>>>>>>>>> later
> >>>>>>>>>> time (a la Maven). On the one hand, you don't need to 
> release a
> >>>>>>>>>> new
> >>>>>>>>>> version
> >>>>>>>>>> of the application each time a dependency is updated. On 
> the other
> >>>>>>>>>> hand,
> >>>>>>>>>> no
> >>>>>>>>>> one is actually running tests to ensure that the versions are
> >>>>>>>>>> really
> >>>>>>>>>> compatible.
> >>>>>>>>>>
> >>>>>>>>>> Is there a way to get module A to see log4j 1.0 and module 
> B to
> >>>>>>>>>> see
> >>>>>>>>>> log4j
> >>>>>>>>>> 1.1 (using separate ClassLoaders)?
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Gili
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> View this message in context:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 
> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5002801.html
> >>>>>>>>>> Sent from the jigsaw-dev mailing list archive at Nabble.com.
> >>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> - DML
> >>>
> >
> >
> > --
> > - DML
> >
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011534.html 
>
> To unsubscribe from Use-cases for version ranges?, click here 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5002801&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTAwMjgwMXwxNTc0MzIxMjQ3>.
> NAML 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>



--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011558.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.

More information about the jigsaw-dev mailing list