Le 16 févr. 07 à 19:38, Yen-Ju Chen a écrit :
So I think most people agree the -trunk and -stable approach for now.
Then we can go through all the stuffs we have.
I divide everything in four categories for now:
1. Bundles and Languages.
2. Frameworks.
3. Services/Private
4. Services/User
The Build, Documentation and Themes probably go -stable automatically.
Build isn't part of the repository, it's just generated dynamically
by etoile.make to handle dependencies between modules.
And since Developers is only for developers,
I think it never goes into -stable.
Not sure of that. Any other opinions?
Let's focus on bundles and languages for now
since there are less than other categories.
** Bundles/Camaelon: go stable
Depends on which targets we decide to associate with 'stable'?
- basic feature set complete
- code quality (readability, conformity to guidelines, polished code,
polished code organization)
- no UI visual glitches
- no UI behavior bugs
- etc.
?
In Camaelon, for example they are some issues: visual glitches,
behavior bugs, conformity to code guidelines, polished code (and
perhaps code organization needs also few minor improvements)…
I think everybody will agree that Camaelon will be part of any
releases starting from now, then… Should we keep it away from
'stable' but include it in 'release' ?
Or we move it to 'stable' and we decide any modules that 'basically
works well' is ready for 'stable' inclusion.
** Bundles/EtoileBehavior: go stable ?
Surely.
** Bundles/EtoileWildMenus: go stable
Issues somewhat similar to Camaelon.
** Bundles/SQLiteClient: NOT go stable, probably deprecated.
We can put it somewhere else. /etoile/other/SQLiteClient along /
etoile/trunk/
** Bundle/WildMenus: NOT go stable, probably deprecated ?
Done.
** Languages/Io: go stable ?
Not immediately, but real soon. I'm currently working on an update of
Io_unstable, latest Io ObjcBridge once merged with my own
modifications will be quite stable in term of syntax, core features
and run-time stability. However I need to submit my patches for
integration into official Io repository. After that I think we can
switch to use Io project directly (I mean getting rid of our own
build system based on gnustep-make to build Io) as you suggest it in
the past since Io build system looks really flexible now that
everything is compilated in term of dynlibs.
Quentin.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
