After upgrading to 3.5.13.1 and getting a bunch of new bugs introduced I started thinking it might be a good idea to release new packages continously as changes are made to the code, instead of doing a big release once every few months. I realize there are some major changes going on in the code and they cannot be released partially. Still I think that thanks to git's branching and merging capabilities it should be possible to merge some smaller changes and bugfixes into master and release them as update. Woludn't that be an easier way to track new bugs introduced to the code? Instead of getting a whole load of bug reports after a major release, bugs would be reported as they appear and would be easier to track down to conrete packages and changes made in the code.

Janek

To a certain extent this is what our SRUs are attempting to do. I do realize that our earlier model of releasing a new version every 1-1.5 years is a bit unrealistic for most users, and hope that Slavek and similarly minded developers continue to cherry pick commits from GIT HEAD to produce additional SRUs in the future.

Regarding continually releasing packages, development is usually riddled with ABI/API breakage (as is quite normal for a project of this size!), and we simply don't have the funding to constantly rebuild and re-upload the entire TDE system.

Tim

On Thursday 11 October 2012 18:08:14 Janek S. wrote:

After upgrading to 3.5.13.1 and getting a bunch of new bugs introduced

I ran aptitude update this morning. I had no updates. So had nothing to upgrade.

I started thinking it might be a good idea to release new packages continously as changes are made to the code,

Slávek has been doing that. Hence my lack of updates/upgrades this morning.

instead of doing a big release once every few months. I realize there are some major changes going on in the code and they cannot be released partially. Still I think that thanks to git's branching and merging capabilities it should be possible to merge some smaller changes and bugfixes into master and release them as update. Woludn't that be an easier way to track new bugs introduced to the code? Instead of getting a whole load of bug reports after a major release, bugs would be reported as they appear and would be easier to track down to conrete packages and changes made in the code.

Those who want to do so, can use Slávek's patches; those who don't want to use the patches, can have it all as one great big splodge.

Best of both worlds.

Lisi

On Thursday 11 of October 2012 19:08:14 Janek S. wrote:

After upgrading to 3.5.13.1 and getting a bunch of new bugs introduced I started thinking it might be a good idea to release new packages continously as changes are made to the code, instead of doing a big release once every few months. I realize there are some major changes going on in the code and they cannot be released partially. Still I think that thanks to git's branching and merging capabilities it should be possible to merge some smaller changes and bugfixes into master and release them as update. Woludn't that be an easier way to track new bugs introduced to the code? Instead of getting a whole load of bug reports after a major release, bugs would be reported as they appear and would be easier to track down to conrete packages and changes made in the code.

Janek

I think that while working on 3.5.13.1, we managed to prepare a development model that could work well. In fact, we now have three options:

1. Stable version - now 3.5.13.1 2. Forthcoming updates for stable version - my ppa 3. Development version - nightly builds

I suppose that in this model, we will continue to develop. Just the fact that the update 3.5.13 => 3.5.13.1 was very big and after a very long time. This can be attributed to the fact that we were at the beginning of the introduction of this development model. Now we will try to prepare SRU versions smaller and more often.

However, about my proposal to use branches for further development I want write later. Let me get some rest :)

Slavek --