Am 28.07.2013 10:47, schrieb Yves Blusseau: > > Le 27 juil. 2013 à 20:08, KP Kirchdoerfer <kap...@users.sourceforge.net> a > écrit : > >> Am 27.07.2013 19:31, schrieb Yves Blusseau: >>> >>> Le 27 juil. 2013 à 11:11, KP Kirchdoerfer <kap...@users.sourceforge.net> a >>> écrit : >>> >>>> Well, seems a problem is that we have developed two different concepts >>>> and naming schemes over time, which are not in sync. >>>> See: >>>> http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=8:8 >>>> >>> Not really a problem. We must have a branch for the next release (it's the >>> master branch). >>> The old branch has been released so only bugfix must be done in it. >> >> You're right. >> >>> So in our case 5.0.0 is release, it's now a maintenance branch. So we must >>> release only bug fix in it). >>> The 5.0.1 or 5.1.0 or 6.0.0 is the new master branch that will be the next >>> release. >>> >>>> Also where do we draw the line between feature and maintenance? Moving >>>> from libnl to libnl3 is rather a feature than a bugfix. But what about >>>> package updates, like shorewall, dnsmasq etc where fixes are provided as >>>> well as new features? >>> This must be in the master branch. >>> For example updating shorewall must be made between 5.0.1 and 5.0.2. >>> 5.0.1 is the master branch. We update it with shore wall update. When 5.0.2 >>> is released, 5.0.2 will be the new master branch and 5.0.1 the new >>> maintenance branch. >> >> You mean when 5.0.*1* is released? >> > Yes sorry > >>> Everything you update is for the NEXT release, so it must be done in the >>> master branch. >>> The maint branch is only to correct bug for people using the last released >>> version. But maint branch must not be update with new version of package, >>> etc… only if it fix a big bug. >> >> (so as a consequence, IF we'd have a real bug in 5.0.0 we'll be able to >> create 5.0.0.1. If so the page linked above should note that.) > > Yes it's that. > > What we can do also is that the master stay in the major release and "rename" > master branch only on new major release (change in one of the first two > digits). > So 5.0.1 stay master and 4.0.3 stay as maint > When 5.1 or 6.0 will be released 5.1 we will change the master branch to the > next version. > 5.0.1 is only a minor release so we don't need to maintain 5.0 branch. > Perhaps it's more easier like this. We only have to tag version in git when > we release the tarball. > > Yves
Yes, sounds easier and more towards how we do releases. I'm keen to tag versions when doing a new release, so that won't be a problem. A question, possibly asked before, how do we keep branches like next in sync with master/maint? E.g. I'd like to publish my work on new boot menu into something else than master so it's available for testing, but don't harm master if something is wrong. Branch "next" would be a good place, but I assume it's that outdated that doing a test within this branch may not give results I expect; the same is true for pu, and will happen with other branches. In the wiki docs you've written that updating branches like next "habitually" is not recommended. So whats the recommended way to keep branches in sync? kp ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
