Stef, I tend to agree, but you want it fairly obvious to the end user that they are wandering onto the bleeding edge when using nano versions:) For example, by default, Metacello would filter out nano versions... Dale ----- "stephane ducasse" <stephane.ducasse(a)gmail.com> wrote: | simon my gut feeling is telling me that four level is too complex. | | Stef | | On Dec 5, 2009, at 5:07 PM, Simon Denier wrote: | | > | > | > Thinking again about the dev process specifically in Moose (not | subprojects such as CAnalyzer, Mondrian...), branches for developer | should be 'nano' releases actually, that is: | > - 4 is a major release of Moose | > - 4.1 is a minor release, but still something consistent | > - 4.2.x should be for release in the main trunk, i.e. mostly dev and | beta version before releasing a minor release (would be 4.2) | > - 4.2.x.y is a branch of one developer (something short-lived, | typically for a task resolution, once finished should be merged in | main trunk) | > | > We could also follow the linux rule: | > - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable | releases | > - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug | fixes | > i.e. minor is odd -> dev version, minor is even -> stable version | > This does not mean we work on two versions in parallel (we dont have | the manpower), but it just to help distinguish between dev and stable | versions | > | > I'm just pushing ideas out of my head. Now, with this process, we | have three main requirements for Moose: | > - making it easy for anybody to retrieve (and identify it) the | latest stable version | > - making integration in the main dev trunk the priority (we have | limited resources, so each developer should take care to merge its | changes in the main trunk, and start over from the main trunk for a | new task, NOT always working in the same branches) | > - managing micro/nano releases from each developer | > | > I'm sorry if this feels too complicated and overly complex, it is | not. I'm just playing with different schemas and see what could work | best. | > | > | ----------------------------------------------------------------------------------------------------------------------------- | > Now of course Metacello should not care about conventions (minor, | micro...) of each project. Your proposition seems reasonable and | flexible enough. | > | > But then, how can I ask for a version with a specific blessing? | > | > | > | > On 4 déc. 2009, at 18:48, Dale Henrichs wrote: | > | >> | >> Thinking off the top of my head, would it be work to supply a | pattern of some sort as an arg? Something like: | >> | >> ConfigurationOfXXX project lastVersion: '*.*' | >> | >> Not a real regex (because of the periods would need to be escaped, | but mainly because reading regex for me is like trying to read | russian:). | >> | >> Maybe best is a special purpose character like '#' in addition to | the standard(?) smalltalk patterns '*' and '?': | >> | >> ConfigurationOfXXX project lastVersion: '#.#' ---> matches all | major.minor | >> ConfigurationOfXXX project lastVersion: '1.#' ---> matches all | 1.minor | >> ConfigurationOfXXX project lastVersion: '*' ---> is current | algorithm | >> ConfigurationOfXXX project lastVersion: '*.0' ---> matches | versions with trailing .0 | >> ConfigurationOfXXX project lastVersion: '?.#' ---> matches single | character major.minor | > | > I dont see what is the use of this one? | > | > | > | >> ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid | >> | >> This one seems to the right approach ... I can add a #match: method | to MetacelloVersionNumber to implement the pattern matching. | >> | >> What do you think? | >> | >> Dale | >> | >> ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: | >> | >> | Suppose I have versions like this: | >> | 1.3.2 #development --> branch by a developer | >> | 1.3.1 #development --> branch by a developer | >> | 1.3 #development --> main trunk, last dev | >> | 1.2 #stable --> main trunk, last stable | >> | | >> | When I perform a ConfigurationOfXXX project lastVersion, I would | like | >> | | >> | to retrieve the config for the last dev version common to | everybody, | >> | | >> | and I would like this to be 1.3, not 1.3.2 which is the work of | one | >> | guy not yet merged in the main trunk. | >> | | >> | Right now, I get 1.3.2 | >> | | >> | Perhaps we could have something like this: | >> | 1.3.2 #branch --> branch by a developer | >> | 1.3.1 #branch --> branch by a developer | >> | 1.3 #development --> main trunk, last dev | >> | 1.2 #stable --> main trunk, last stable | >> | | >> | and branch would be an 'unstable' tag ignored by the loader when | >> | asking for latestVersion or lastVersion (and veryLastVersion | could | >> | retrieve the latest version, be it a branch, dev, or stable). | >> | | >> | I have no special requirements here, I'm just playing with the | idea | >> | and process of how to manage micro releases with Metacello. | >> | | >> | -- | >> | Simon | > | > -- | > Simon | > | > | >