5 Dec
2009
5 Dec
'09
6:12 p.m.
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(a)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(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