Hi Helio, you're right to raise this now. Let's include the whole ML for this.
The issue here is that our current development model is not fully adapted to minor releases. As an alpha/beta product, we can afford that and unless we come accross highly critical issues (security or release-is-completely-borked), we don't need to deal with this stuff. It saves a lot of time. That said, it is time to move to a better model as 1.0 is coming soon and testing the product includes testing the release cycle :). The current concern is that we have a lot of modules, all of which are on one release cycle (liblxqt's). This is useful as doing one release per component is fairly insane; depending on liblxqt instead gives us the modularity we want without having to do this sort of cycle. For what it's worth, lxde classic is on a fully independent cycle for all its modules, but it also releases infrequently. I personally believe having *one* version is a lot less confusing for the users, but we can't afford re-releasing the entire suite if we find a security issue in eg. one of the panel plugins. My solution is to have a separate release dot for the components. In essence, LXQt 0.9.0 would not be 0.9.0, but LXQt 0.9 and we'd have lxqt-panel 0.9.0, lxqt-panel 0.9.1 etc. If a 0.9.1 seems needed in such or such component we branch it off the tag at that point into stable/0.9.1 - no need to do it earlier. This is actually compatible with the current release process and seems very uninvasive. Thoughts? 2015-02-08 15:11 GMT+01:00 Helio Chissini de Castro <he...@kde.org>: > Hello again guys > > I would like to raise the topic on the development and branch system. > > As 0.9.0 is out on the world, how is the proper procedure to go on > minor releases ? > The proper questions are: > > - Should we have a 0.9 branch ? > - Should we need tag 0.9.0 to remember when the tarballs are set ? > - Considering no branch will be done, how to avoid major features to > be merged on master. We will follow the kernel mode where Jerome is > the git master and will pick the proper pull requests, so never a > branch ? > > I know this is too soon on the 0.9.0 release, but i'm already thinking > on next minor and major releases as as well and concerned that if i > want today compare the master with the released 0.8 and 0.9 releases, > i would rely of not so exact method od the day of the tarballs. > > Sorry for annoying everyone on Sunday > Have a good weekend, Helio ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
