On 4 March 2013 15:30, Wolodja Wentland <babi...@gmail.com> wrote: > On Mon, Mar 04, 2013 at 15:04 +0100, Michał Marczyk wrote: > >> On the other hand, if you care about securing your project, pulling in >> the latest bugfixes etc., you will need to monitor new releases >> anyway, regardless of the version numbering scheme used by their >> maintainers. > > And then release a new version for every new release of one of my depedencies?
For a security fix, absolutely (although the users should upgrade the dependency on their side as soon as they learn about the problem anyway). For a different bug fix, maybe, depending on if you care about the bug. >> > * Library authors would be more concerned about providing a stable >> > interface for all releases that fall into a certain version span >> >> Those library authors who care about this already act in this way. > > Exactly and I would like to take advantage of this. I also think that > establishing reasonable versioning and using version ranges as the norm would > increase the pressure to, well, adhere to the norm by making sure that one > does not break backward compatibility in a minor release. You can take advantage of this by using the new versions without changing your old code. Having this happen automatically -- as in, 1.4.0 gets pulled during the build on Monday, then 1.4.1 on Tuesday with no explicit action to cause it on your part -- means throwing away repeatability of your top-level build. I'm just not convinced that is a good idea. > Yes, a lot of people don't really care in which language a tool is written > (nor should they) and simply want to install that software using their > preferred packaging system. Sure, and there's no problem with that: > One reason for the need to not ship the same library all over again and in > using version ranges is one of security. Imagine if a library is found to be > buggy in version 1.2.3 and that a bugfix is available in 1.2.4. In order to > take advantage of this one can either upgrade that single library on a system > and /all other/ applications and libraries using this would be patched > immediately or you could force every consumer to change their dependency on > 1.2.3 to 1.2.4 and release a new version. The version used by an app is just the version in the jar put on the classpath by its launcher. For packaged apps, this will tend to be a symlink to some sort of "latest in the 1.4.x branch" release jar. The story for .so files is exactly the same (there's tons of symlinks in /usr/lib on an Ubuntu system). And what happens if 1.4.8 actually breaks compatibility with 1.4.7 while introducing a security fix? Well, if you're maintaining the package, you might actually backport the fix. Of course that's not very relevant to lots of Clojure software written today to be deployed to a server / "cloud" / run locally to crunch some data etc. where I have see no problem with simply updating the top-level project.clj / pom.xml. > To give an example: I could write code against the standard library that ships > with Python 2.7. I would expect that my code runs with all releases in the > 2.7.* version range and would like to express that. > > See, for example, http://www.python.org/dev/peps/pep-0426/#version-scheme > for a relevant PEP in the Python community and I am sure you'll find many > other examples for other languages. Is it typical of Python packages to use non-trivial ranges? (As in, version specifiers which are not either == or purely >=.) The handful of packages I've examined tend to be apps and use == or libraries and use >= with no upper bound. I do recall that pip, virtualenv & friends allow one to pull in the latest versions of packages easily -- and then to freeze the requirements for deployment, thereby avoiding headaches with the equivalent of non-repeatable builds. On 4 March 2013 16:15, Wolodja Wentland <babi...@gmail.com> wrote: > On Mon, Mar 04, 2013 at 09:54 -0500, Chas Emerick wrote: > […] > > Thanks for this mail! I think it is very helpful in the debate. The notion of > "soft dependencies" seems to be quite ridiculous (as you could just have an > unversioned one), but the real problem seem to be that there is no way to > express the notion of: > > I (should) work with all stable releases in the 1.4.* branch of libfoo > > among many other reasonable schemes. I'd say you do this by including [libfoo "1.4.0"] in your :dependencies. If your library then breaks because 1.4.8 comes out with a breaking change and some project's will have both libfoo-1.4.8 and your library on the classpath, then that is libfoo's fault. Wrapping up, I'd say that using version ranges feels like imposing something like semver on your dependencies. Unless you maintain those dependencies, you simply can't do it. If they follow the convention, you can take advantage and upgrade to new releases with ease; if they don't, there's no value in writing down an expectation to the contrary in your build spec. Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
