Hi!
Actually there is quite many things to do for the new release (agree the content, get the agreed content in etc.) but if we are assuming content is agreed to be one change + version bumps then the flow is pretty much as follows: 1. Create new branch for the release (not needed if updating existing release) 2. Do version bumps for submodules in that new branch + create a fix in that new branch (not needed if updating existing release) 3. Integrate fix + version bumps. When we are doing new release we need to bump version in each submodule as well. Knowing our CI stability it will take a while when all version bumps are in submodules. Without version bump we just need to integrate that one change in one submodule 4. Integrate submodule changes in qt5.git. If all modules are changed this step will most probably fail few times because of CI instability (flaky tests, network issues etc). With change in one submodule this is most probably much easier & will go through much quicker 5. Merge qt5.git in our super repository containing qt5.git + enterprise features. 6. Run packaging tools for src and binary packages (patch content, package content in suitable form for installers). 7. Update packaging configurations. If we are doing new release we need to create all new packaging configurations for that. When updating existing release we don't need to change configurations at all. We just need to update package version number for online repository configurations. 8. Update release test automation configurations and tests. (not needed if updating existing release) 9. Create packages for the release (Online repository and offline inataller packages, LGPL and commercial ones) 10. Test the release. If we update existing release with one change it is much easier to test. We need just test that the fix is in and fixes the issue + don't break anything else. And of course test that packaging went ok. So we can rely on RTA in this case pretty much but with totally new release we need significantly more manual test effort in addition and that takes time (testing + collecting results). 11. Publish the release. There is also more configuration changes in delivery tools if doing new release instead of updating old one. All these take considerable amount of time and Effort. Doing new release instead of updating old one is much harder and here is also more places where something might go wrong. That's why updating old release is much safer. br, jani ________________________________ From: Giuseppe D'Angelo <[email protected]> Sent: Wednesday, June 22, 2016 11:04 AM To: Jani Heikkinen Cc: Thiago Macieira; [email protected] Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen <[email protected]<mailto:[email protected]>> wrote: In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker. This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes? Thank you, -- Giuseppe D'Angelo
_______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
