Hi Erich; glad you raised these questions.
Am Freitag, 21. November 2014, 22:51:39 schrieb Erich Titl: > Hi KP > > Just for my understandig, what is the numbering related to? The numbering scheme hasn't changed since outlined ten years ago. http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=8:8 To summarize with updated examples: The first number (v 5 nowadays) is reserved for updates that breaks the toolchain, like a new uclibc version. The toolchain, kernel and packages needs to be replaced all at once when updating. The second number (v5.1) is reserved for changes that cause incompatibilities in various areas, like a major kernel update, which requires to update all kernel related packages, when updating to this release. Also changes to the base system and new features (apkg for example) that are probably not backward compatible should go into this versions. The third number (5.1.2) shall only provide package updates, security updates and bugfixes. It should be almost backwards compatible, and users shall be able to replace packages with older versions, if something went wrong. They should also be able just to grab a new package instead of updating everything. We have had, and I hope we will have again, a webpage, where new packages could be downloaded and applied to a running system without the need to download one of the images and either install the whole image or to get a new package out of a image, a process which is not self-explaining. But unfortunately this option has been lost due to the restrictions of the the current CMS - just see the packages page, which simply does not work any more. (I guess the content has outgrown the CMS database fields) http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=30&MMN_position=44:44 > What milestones have been defined for these releases? There has been a time we tried to work with milestones (TRAC), but it didn't worked out well. First of all we've lost TRAC due to SF changes and I don't see a usable replacement. But more important: There has been not enough manpower to take the milestones seriously, and while being eager to let users access security updates, bugfixes and new features, we've moved so-called milestones from one release to the next. I also do have "milestones" in mind, like adding strongswan finally, but whilst I offered packages to test, nobody jumped in and helped to finish that task. So it's moved to some time later. But in the meantime other changes have accumulated that are ready for release. And I think it's better to create a new versions with these changes, than to wait forever just to fit a "milestone" driven release. > Is it a date driven scheme or do we attach a certain level of confidence to > these releases? Difficult to say :) Rule of thumb is to release without known bugs, but other than there is no scheme. Over the years the tools improved and it occured that the "release early, release often" seems to be the best strategy for us. We only have a few internal testers, so offering betas and rc versions are important if we want any feedback. Unfortunately beta versions and release candidates downloads are signifcant lower then for final versions. So bugs/problems are often detected after a major release (see 5.0 bugs), another reason providing smaller updates quickly. Maybe it's based on the fact that users usually don't update often a piece of hard- and software that "just works". Putting security issues at beside, LEAF routers runs for monthes if not years without problem, and if one occurs, it's often enough to reboot for another year. A LEAF router is sometimes a forgotten piece in a user infrastructure I guess, IMHO not too bad as a quality sign for our work :) > How is it decided that the software state is stable and how is that > verified? Decided by time and feedback, or more often, lack of. I know that this can be improved a lot and I'm open to suggestions and help. BTW: If you ask because you are looking for your apkg changes - I haven't tested yet. And what how they relate to cpumemhd's work committed to master? kp ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
