It’s in a few days and we want to keep the changes to the strict minimum
If we refrain from merging the pending pull requests because 0.5.1 is coming we’re effectively blocking progress
What about creating 0.5.1 from the HEAD of master instead ? And cherry-pick -x the relevant changes from develop. This is essentially what is done when backporting commits from a development branch to a stable branch. We won’t need to merge back 0.5.1 to develop because it will only contain commits that have been cherry-picked from develop which is a nice simplification. We won’t need to worry about 0.6 conflicting either as long as we make sure all commits cherry-pick with no conflict, which should not be difficult since develop will only drift away during a few days.
Nice timing @dachary, we were just discussing this in the SF office. As you know we were planning 0.5.1 just for the Tor apt changes - and while there’s been some excellent progress on preparing our Tor apt mirror on the infrastructure side this week, we’re probably going to need additional time to get these changes production-ready for SecureDrop. An additional concern is doing this right before the holidays: if any issues arise, administrators may not be available due to their holiday vacation. That said, I propose we combine what was planned for 0.5.1 (tentatively planned for next week) and 0.5.2 (a regular release planned alongside the next release of Tails in January), which gives us additional time to QA these changes and send them to production. What do you think? Also we should discuss this as a group first during the 10am Pacific SecureDrop meeting tomorrow to make sure we reach consensus on this and that there are no other concerns. In the unlikely event we have rapid progress and decide to go for the release, let’s go with your plan above - we definitely don’t want to QA a bunch more changes - so in the meantime we can proceed with merging pull requests into develop that change strings as usual
Sounds good ! The idea of cherry-picking is only good for releasing a few commits. And you’re right: it may be wiser to take time instead of rushing and risking problems right during hollidays
I propose we combine what was planned for 0.5.1 (tentatively planned for next week) and 0.5.2 (a regular release planned alongside the next release of Tails in January), which gives us additional time to QA these changes and send them to production.
We’ll hash out the details in the roadmap meeting, but that plan is sound. Let’s not break anything during the season when most Admins will be hard to contact, and likely off-site.
Based on the above, doing so won’t be necessary. That said, I’d like to counsel against breaking the typical workflow for anything but hotfix releases. In the past, we’ve allowed the branches to diverge, and developed a very large backlog in develop that slowed down shipping releases (resolved as of 0.4).
We’ll hash out the details in the roadmap meeting, but that plan is sound. Let’s not break anything during the season when most Admins will be hard to contact, and likely off-site.