The AU team slates a release at the end of every month to get all the smaller pieces of work out and available for instances. This release is usually a 1.n.n, as to date they have been smaller releases and not worthy of a 1.n.
Schedule for these releases:
Apr 28 - 1.8.9
May 26 - 1.8.11
Jun 30 - 1.8.12
Jul 28 - 1.8.13
Aug 25 - 1.8.14
September 27 - 1.9
October 20 - 1.10 (pending)
November 24
December 15 (or the Wednesday after)
Note: if a team requires a small change or bug fix for their instance then this can be accommodated outside of these end of month planned releases.
Larger feature releases
When larger features are delivered as part of a project (e.g. Spree Upgrade, Multilingual) we will schedule a stand-alone 1.n release.
Estimated schedule for project work in the pipeline:
Was chatting with the AU team about how we manage releases for the year. Last year we started out with a plan to have a release at the end of every month…which we did fairly consistently until we got to the point where we didn’t have anything major to release and started putting out ad-hoc dot point releases (e.g. 1.8.8 which was released this week).
We were thinking, now that there is a lot of activity happening and more and more code being merged into master by non-AU team people that it was worth revisiting this idea and scheduling some kind of release on the last friday of every month.
Random thoughts about this:
Everyone in the community will know to expect a release at the end of every month.
Those putting issues through the pipeline will know if they want something in a release that it has to be ready by the Wednesday before release day. Including being reviewed and merged to master.
The AU team can then better manage their end of the pipeline and not be up till the wee hours of the morning trying to get the big queue of things waiting to be merged reviewed and pushed to master on the day of the release (@oeoeaio I’m looking at you ) .
We can decide on the day whether there is enough to release and whether it deserves a full dot point release (e.g. 1.9) or is a smaller release (e.g. 1.8.9).
We don’t have to only put out releases on this day, we can also do it at other points when there is a need (e.g. a severe bug is found or a feature release is ready mid-month).
Thoughts? If everyone is ok with this then the next release will be March 31 (possibly 1.8.9 but also possibly 1.9 if Standing Orders beta functionality is ready to go as planned).
Perhaps moving forward, and particularly as we increase the number of people certified to test/merge, it would be good to cycle through things waiting for merge on a more regular basis.
One thing that is often a challenge from my perspective, is that the UK team does a bunch of work on an issue, tests it, gets it to the point that we need some final feedback from the Aus team, and then the Aus team get to look at it hours before the next release. If they let us know that some issue is a blocker, we have a few hours to get something through our whole pipe again otherwise we have to wait a month until the next release. As you can imagine, if we have a user waiting for a feature it doesn’t come across well and causes huge delays. Sometimes this happens twice on the same feature, meaning a small fix takes months to come through.
Perhaps we can have a weekly cycle of testing and merging so that there is opportunity for minor tweaks between the frantic rush to merge anything that you either can with ease or that feels a priority to the merging team before the release?
I know you are at capacity… so the certifying others to test and merge feels like a huge priority on this point.
My comment here is related to what I said in this other thread:
IMHO if you reach a point where the PRs are small enough to be reviewed / tested / merged it makes more sense to have multiple releases per month. A 1 month release window seems too big to me and I second @lin_d_hop opinion.
I understand that having a release per week can be overwhelming for AUS right now but maybe this could be a kind of goal for us since it would enforce to bring more people into that core contributors team from outside AUS.
@lin_d_hop, I think (as you suggested) the problem you have highlighted is more related to a bottleneck in the amount of code review being done, and also a lack of clarity around which issues are highest priority, who each issue is waiting for input from, and what needs to be done to move the issue forward. I really don’t feel at this stage that moving to a weekly release cycle is going to help us much in and of itself. What do you think?
Release frequency really has very little to do with the frequency with which code is actually pulled into the codebase.
That said, I am personally generally supportive of instances deploying the most up-to-date code into production if we have code that is ready to go and they really want to keep up-to-date. What that looks like I’m not really sure. As you know, Aus production is bleeding edge by definition at the moment, so for others I suppose we could do something like edge releases in between the more comprehensively battle tested monthly releases? Is this something that other instances really want? It would add a bit of overhead to our existing schedule…
As an alternative: we could make our main goal to improve the flow of PRs through and into the codebase by improving our management and communication around where things are at, and by aiming to reduce the size/complexity of each individual PR. We could stick to a monthly release schedule which would hopefully include a greater amount of code being released in a timely manner (given the above). Additional point releases could be made on an ad-hoc basis where required/requested by instances. Does this sound workable?
Definitely think that smaller PRs that can be more easily reviewed and tested would allow us to pull in more frequently, and would probably help with allowing more people to try their hand at reviewing, which would help us with our other problem of up-skilling a core contributors team.
As Rob said, the processing of pull requests are usually independent of releases. It’s just that at the moment, people try to squeeze in as much as possible before a release. I think it would be better to have a more continuous stream of pull requests being merged. If it helps to release more often so that you can relax with your pull requests, then that’s a good idea. I don’t think that weekly is achievable by the Aus team at the moment. Currently, we work only three days a week so that it would be a release every three working days. That’s not enough time. Maybe we can do two releases per month? Danni proposed the last Friday of the month. What do you think about two weeks before that as well? Two weeks is a common sprint duration (but that’s usually 10 working days).
We should also think about the translation window. Two weeks might not be enough for all translator teams to translate everything. In that case they don’t have a fully translated release, before the source file is updated for the next release.
The UK team could probably use the master branch and tag their production deploys. But people who need translations can’t do that as easily.
Thoughts on this @sigmundpetersen@MyriamBoure? Given there was an issue around losing translations last release I’m curious to understand how translations fit into the release process.
For Norway monthly releases are enough. It also fits well into our translation process as we don’t have the resources yet for it to be strict and efficient.
Sounds good. Yeah the issue I was speaking of was the issue around the squeezing of so many PRs around releases. I’m not worried so much about regular releases as regular merges and feedback cycles. The UK team is very conscious of not pinging the aus team too often and trying to use processes like the Aus Review label. However with the way we are all working this means sometimes things fall through the cracks and aren’t noticed for a while.
I understand weekly releases are too much and also know we can work around this (and have done) in the UK. However merges do become important, particularly when we aim to keep PRs small and separating branches.
So yeah, agreed @oeoeaio… no need for weekly releases. High need for faster code review turn around… which I know we are working on
Thank you all for this proposal! I think releases twice a month as proposed by @maikel sounds great, especially when I’m thinking about projects we are trying to “sell” are based on 10 days sprints (2 weeks) so that would fit pretty good.
As suggested by @Rachel in some previous discussion about the potential big project in France, she suggested sprints that start/end in middle-week-days not on Monday/Friday because it makes it hard to manage when people leave a bit earlier to go on week-ends, and if there is an issue you have a bad week-end and you end up working to fix unexpected issues If the release were for ex on Tuesday or Wednesday, we could end up the sprint the same day so we can review the new version released, collect feedback and iterate on that for next sprint. Else I guess we would just test on a staging deployment of the last version of the code including the sprint PR, I guess we can also do it that way… I’m not familiar with such processes yet, what do you think?
I think generally we should try to stick to the “twice a month release” and as all says, send PR and merge regularly. But I would suggest we keep an open window for “extra releases” especially when there is a need to fix a bug that is really annoying.
The AU team only work between Wed-Fri @MyriamBoure, which is why they usually end up being released on a Friday (so we have the 3 days to get enough through the pipe in that week).
We can look at changing so that we release on a Wednesday, however we aren’t at present working with sprints where we decide what to release within a 2 week bracket, or iterating on releases in any a formal way. This is mainly due to the limited amount of time everyone has, the limited budget, and the variable issues being worked on, and hours and days and locations that people work in.
We in the AU have more of a Kanban approach to delivery where we have a backlog and we prioritise that so that each dev picks the next most important thing off the list (or I assign stuff as other important things come up). If we were more organised then I can see this working but I think I prefer the idea of each team in country deciding how they want to run their work through their pipeline, and having the code review and test process run in a more lean approach where when it is ready it is put into the AU team’s pipe by marking the PRs with ‘Aus Review’.
In my experience to date with the OFN, for us to run with Scrum methodology you must have someone with a decent amount of time to act as scrum master for the global team of dev contributors (and UX, and Testers) who do varying numbers of hours on varying days (including weekends) and in various locations around the world. This is why I believe a Kanban approach is the better option for us at present, where devs pick up an issue from a backlog and run it through the pipe; and then a lean factory approach where they then put the resulting PR into the AU review and merge process and let the other team run it through to done.
Given the conflict the AU team often has in deciding whether to do actual development (e.g. standing orders), or code review/support/push, we couldn’t work in sprints because our priorities change every day almost. We’re even more agile that way
) .
If the release were for ex on Tuesday or Wednesday, we could end up the sprint the same day so we can review the new version released, collect feedback and iterate on that for next sprint. Else I guess we would just test on a staging deployment of the last version of the code including the sprint PR, I guess we can also do it that way… I’m not familiar with such processes yet, what do you think?