Quoting Nathan Ingersoll <[EMAIL PROTECTED]>: > One idea I discussed with Vincent today is that our lack of releases > has caused many users to lose interest and stop taking notice of the > project. I realize that there is a lot of talk surrounding changes to > core infrastructure (data lib, graphics, scripting language, etc), but > has there been any thought recently put into how our release process > should be structured? There used to be a TODO list for e17, and that > has been moved to Trac, but has anyone took a hard look at what is > necessary for cutting a stable release? Even if we don't release e17 > 1.0, we may be able to move the core libs towards releases like eet.
Some ideas I and others have: 1) We must release the core libs (evas, ecore, embryo, edje, efreet and e_dbus, that is what is needed by e17). So we must discuss to what must be done for each of them before a release. Here what I think. You can add other things I have forgotten. * embryo: is in a very good shape. raster wanted to release it later because he wants to look at lua for scripting. I think that it is a very bad idea, and should be delayed for the next version. What may lack is documentation. * evas: also in a very good shape, but several things wanted to be done: api changes in polygons, gradient and data types (see below). Documentation must be improved too. Although polygons can be done in a rather short amount of time, gradient stuff can take a long time and maybe can be done (with other things like vgfx) in the next evas major release. Note that Nathan and me agreed on the fact that, today, we should have an evas 3.*, and not 0.9... * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data types. See next point * evas and ecore: data types. The problem is that it will break abi if we change the data types. See below for a "solution" * edje: except the problem of data types, I don't see any major flaw. * efreet and e_dbus: I don't know much about them. They are used with e17 without problem. Cedric told me that he wanted to speed up efreet. There is the problem of data types, though. The problem with data types is that it will break ABI and API. So we must decide if we release with or without the change in data types. A solution is to "release" with number version 0.10 (current version number is 0.9.9) without data type changes and warns that there will be big changes for 1.0. 2) A release manager must be named. What he should do: * decide which library may be released because of a certain amount of important bugs have been fixed. Of course, this should be discussed in the ML for example. * sent mails to warn about pre-releases (in that period, only bug fixes and doc changes are allowed. Maybe other things i can't think of.) and releases * of course, provide the tar balls for pre-releases and releases * maybe add news on some sites like osnews, /., freshmeat or phoronix Even if there are 0.10 releases before a 1.0, the fact that we announce such release is a good thing. As an example, Kim is doing e16 releases periodically. Each time one is done, a user announce that on osnews. And i often read in those news that people are happy to see that e16 is still maintained. Comments, ideas ? Vincent ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
