On 12-06-15 09:34, Esteban Lorenzano wrote:
Project A uses for instance Seaside stable which is, when Project A
starts Seaside 3.0
time after owner tries to load Project A… but since then stable from
Seaside has move from Seaside 3.0, to 3.1.2
Seaside is the one example where we are using semantic versioning,
precisely because we ran into the problems you described.
We have #'release3', #'release3.0' #'release3.1' and will soon have
#'release3.2'. #'release3' points to #'release3.1', so if you don't
care about the api changes from 3.0 to 3.1 you'll just use the
latest stable. Otherwise, use #'release3.1'.
We'll do bug fixes on the numbered versions, and make sure that they
work with the latest versions. Depending on a numbered version will
force you to keep up with every change in Seaside, especially because a
lot of new versions are due to changes in Pharo.
So, if you depend on Seaside, Grease or Magritte: you probably don't
want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'.
that of course introduces other kind of problems, like: what happens
if I want to install Project A who depends on Seaside/3.0 and
>Project B who depends on Seaside/3.0.2
Yep, both should depend on #'release3.0'. That way, your code might
even run on Pharo 4, and profit from the bug fixes done between 3.0.2
and the current 3.0.16
Stephan
