After so many years my fingers are tired of typing long branch names such as “open-release/nutmeg.master”. I propose that for Palm we name the release branch “release/palm”. Then, release tags should be named “release/palm.beta1”, “release/palm.1”, etc. To ease the transition, I propose that we also create “release/olive.X” and “release/nutmeg.X” tags.
I understand that this change is easier said than done. We will probably have to modify quite a few CI scripts and re-train our muscle memory. As far as Tutor is concerned, the change would be pretty minor, but I’m curious to hear about the impact for other organisations.
This doesn’t have to block your proposal, but one of the reasons we didn’t name the branches that way to start was that we already had branches (and tags) starting with “release” for the deploys to edx.org, though they don’t have the slash.
My motivation is less a practical one and more philosophical, though. As compared to some other open source communities, I’ve always thought that the way Open edX distinguishes between what is community-facing and what is edx.org-specific a little… backwards.
“Open source PRs” (OSPRs) and the case in point, “open-release” are two terms that I’d love to see changed into “PRs” and “releases”. And if by any chance the distinction needs to persist, it should go the other way: “edx PRs” and “edx-org-release”. (All of which should in fact not live in the openedx repos at all, but… one step at a time, I guess.)
Otherwise I like the recomended approach as you suggested, @regis. To read that back:
A single release/zebrawood branch where all updates go into.
I agree that our de facto process for managing releses might not be efficient, I hope this or any future change would adress the following issues or pain points:
Make it easy to backport a commit(s) to the release branch
Make it possible to release a particular repo/compoenent/IDA…etc without relying on releasing all other repos.
For 1 porbably we might need a bot or kind of automation which by itself require extensive topic.
For 2, to give you an example, imagine a particular MFE, got an important necessary fix, just one day after we release olive.1. Now should that MFE wait for olive.2? so people can use it… Of course there is a way around to set the branch/commit-id in tutor-mfe… but I don’t think it’s the most efficient way, or sustainable.
Note: I just bring an example for MFE, but it can be any thing, discovery service, edx-platform…etc
May be I went slightly of topic, but just had to mention it, and I do agree with Regis suggestion.
I think this it’s the core reasoning why I would like to see this happen. What works for most organizations in the community should receive the standard treatment. If there are exceptions made for a particular organization, then those need to be specified.
In Tutor, we address this issue by cherry-picking individual commits between minor releases. This is not ideal, but it’s the best I can do. @ghassan do you have any better idea?
I’m supportive of doing this over time, but would like to hear from @jmbowman on what would be a reasonable amount of time for continuous delivery to be updated.
I’ll note that the original post proposed making the change because “open-release” was too long to type. The thread has evolved
I do think that it would be better to have a standard way denoting branches for all community members.
I would suggest that we namespace branches that originate from a specific member of the community to distinguish them from ones that are endorsed by the project and relevant to all community members.
I propose, for example, we migrate
release
to
2u/release
or similar.
I think that this should apply to tags as well.
I’ll acknowledge it remains a little odd to push organizational branches and tags to the canonical upstream. However, I don’t think we should entertain changing this now. That would be a much bigger change and I think it is very valuable knowing that a tag or branch represents code that was battle tested in production by millions of users.
I don’t have a spesfic thing in mind, I can specualte it can be something like:
A depencey of tutor/tutor-plugin released a new tag
A web hook from that repo trigger tutor CI/CD to build the image with new tag
A new image of that tutor service is relelesed.
Beside that I think ideally it would be great that whenever a new change on something that tutor depends on to build an image would trigger a tutotr test, at least to ensure the image can be built successfully. Probably the test would be triggerd if the branch if the target branch is a release one.
