[Development] Starting preparations for Qt 5.1
Hi, Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote: On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Since you list several reasons why we may well need a Qt 5.0.3, then why not do it properly and just make a branch as Andy suggests? What is the downside? Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On 3/18/13 12:04 PM, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote: On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Since you list several reasons why we may well need a Qt 5.0.3, then why not do it properly and just make a branch as Andy suggests? What is the downside? If required, we can always create that branch later on (ie. branch from the latest sha1 in stable before we merged dev back to stable). Is there a real reason why we should do it now? I don't really see one. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
