Simon,

I've been thinking about the same problems for GLASS ... I want it to be possible for individual developers to release bugfixes/improvements for sharing, but hadn't thought too far into it ... nano releases sounds like the right way to go...as far as a convention ...

Re: filtering on version and blessing ... I think that the special '#' character in patterns should stay ... blessings don't have a sort order so at the moment they are odd beasts ... for example I can't say 'belssing > #alpha' ... so perhaps we need to define a sort order for blessings ... I lean away from a canonical list of blessings, so folks would need to be able to add blessings/priority to a project ...

Have to come up with the low-level filtering api and then create come higher level helper methods ... I'm open to suggestions at the moment...

Dale

----- "Simon Denier" Simon.Denier@inria.fr 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@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