Le 4 nov. 08 à 16:49, David Chisnall a écrit : > On 4 Nov 2008, at 15:42, Quentin Mathé wrote: > >> Hi, >> >> I was thinking about the fact we got to update the VERSION variable >> for the frameworks that are going to be part of the next release 0.4. > > Good idea. > >> For example, EtoileFoundation declares VERSION = 0.1, do you agree to >> update to 0.4 all stable frameworks in both trunk and stable >> branches? >> David, is this also ok for frameworks such as LanguageKit, MediaKit >> etc.? > > Makes sense. There might be some confusion with the version number > for LanguageKit running backwards briefly, but it's probably better to > do that now than later.
Yes. >> Is there anything else we should take in account or discuss for the >> versionning of modules? I haven't give any thoughts to the need of >> packagers… > > I think sensible monotonic versions will help packagers. I do wonder > if we should separate out the Étoilé version and the framework > version. For example, I doubt OgreKit will change between 0.4.0 and > 0.4.1, but LanguageKit will. Updating both of them to 0.4.1 doesn't > entirely make sense. Yes, that's the issue. Independent module versions makes the changes more obvious for each module. > Perhaps we should declare ETOILE_VERSION=0.4 in > etoile.make and have each framework use $(ETOILE_VERSION).0 now and > bump that to .1 if it changes for 0.4.1? Even this isn't ideal, since > it makes it difficult to track which components have changed with an > increase in Étoilé version. Right. Another problem with this scheme is that it's hard to make a standalone release of a single module without making a new Étoilé release. For example, web browsers or dev tools are very often updated between each OS release. I suppose at some point, we might want to do a LanguageKit release without updating Étoilé. For example, frameworks may be used outside of Étoilé (like on Mac OS X). Also if we integrate a module whose development started outside of Étoilé, it's probably better to keep its versioning scheme. The worst would be to have a module at version 1.5 that got integrated into Étoilé 0.5 for example, then the module version will have to be moved backwards with many potential conflicts. A last point in favor of a separate versioning scheme per module is that it might allow to merge back a forked module (such as our OgreKit) and get its version in sync with the original one more easily. > GNOME and KDE both version their > components separately from the desktop environment releases, Yes, it looks like that's what they are doing. However for some modules they use they seem to use the environment release version. For example, Cheese <http://projects.gnome.org/cheese/> or gnome-vfs. We might choose to do so for our core frameworks (EF, ES, CO, ETUI), not really sure though. > so I > don't have a problem with us doing that, as long as we remember to > increment the versions for everything that's changed before each > release ok. Sounds more reasonable to take this path now that we have discussed the matter. > (i.e. first commit in stable after a release should bump the > revision number). Sounds good. I would only add the version should be bumped in both stable and trunk at that time. Does that make sense? Any other opinions or comments? Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
