it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice… who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say “3.*”)
btw… IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever… they are used to describe and publish projects people actually can download and use. Any version: 3.0 3.0.1 3.1 … etc. is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. we need to separate the concept of “artifact released” and “development branch”, and we need to stop using versions as commits. In my opinion development cycle should be: we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc. I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. cheers, Esteban > On 12 Jun 2015, at 10:04, Stephan Eggermont <step...@stack.nl> wrote: > > 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 > > > >
