Please simply create a new branch with the new name (I think it is “unpublished”). After the transition is complete, we can then delete “master”. This is standard practice for a transition–separate create from delete instead of a disruptive update.
3 Likes
+1 to this being standard practice. Also goes for larger refractors, rewrites, and migrations. SOP is fork, change, redirect, delete. Following this procedure consistently may have made, for example, the text page upgrade less disruptive and easier to coordinate over the last few months.
PS: y’all may be interested in git symbolic-ref refs/heads/master refs/heads/unpublished 
1 Like
I’ve transitioned Bilara webapp to using the unpublished branch, which fulfills exactly the same role as master branch. Note that master branch still exists and we can manually synchronize them, but please stop using master or alias it to unpublished asap (aliases are local to a git repository).
I have made the default branch on github bilara-data the unpublished branch. Previously we had decided to make the default the published branch.
On github the default branch determines two basically things: First it is the default branch for clones and the branch which a user sees by default when navigating to the project page on github. Secondly, it determines the branch which pull requests are made against.
In the interest of making the transition as painless as possible, I decided to make the unpublished branch fully equivalent to the master branch.
In the future, we might still set the default branch to published, but note that this means it will be the default branch which pull requests are made against, which is not desirable in most cases.
I was actually thinking that it might be better to use a separate repository for the published texts. That is to say, that bilara-data repository would be strictly the working repository for the bilara webapp, and then a completely separate repository on Github, such as published-texts which is intended to be cloned by people who just want the published texts, this repo could also include texts which never went via the Bilara webapp/repo. The bilara backend itself doesn’t care whether the published and unpublished branches are in the same or different repos.
I feel that two separate repos would result in greater clarity / less confusion.
2 Likes
I’m really not sure of this change, Blake. It seems to add complexity to the process without actually solving any problems. We need the published texts in a published place—whether a repo or a branch—and we still don’t have that. Instead your proposal passes the burden of aliassing unpublished to master to developers, but they shouldn’t ever see that. They should only ever see published. Why are they futzing around with unpublished, only to futz again with published when, in some unspecified future, we actually create published?
And as to PRs going to the published branch by default, so what? They have to go somewhere by default. PRs should only ever be made by trusted people, and if they can work with bilara-data backend, they can set the PR to merge to published or unpublished as appropriate. And if they get it wrong, well, that’s why PRs are checked. It’s just selecting one or other option from a menu, I can’t see that this is an issue at all.
Whether you’re right to say published is the correct branch against which to make PRs is desirable in “most cases” I could not say. Generally speaking users won’t be making PRs at all. And when/if they do, it seems to me that there are perfectly good use cases for doing so to published, for example, making corrections to published texts.
It seems to me the whole point of the Git workflow is to do exactly what we want to do. Work on stuff, and when ready, merge it to a main branch for serving to applications. Why reinvent the wheel?
Why? Is there a use case for this?
2 Likes
Voice staging is now also using the unpublished branch along with _publication.json. After we release Voice, we’ll be able to explore removing master. Voice currently does not yet use the other publication branches. It relies instead totally on _publication.json in the unpublished branch.
1 Like
I am really sorry about this Karl, but IMHO this whole thing has been a mistake. Unpublished is never meant to be used by apps. Why on earth would we expose an “unpublished” text for, you know, publication? That was the whole point of having a published branch, so it was clear what is published! We should not be passing the burden to you of multiple unclear changes.
The branch you should use to consume data is published. Full stop. Published does not exist yet, so there is no call to make any changes to Voice. Just keep using master as before and wait until we sort this out. Master will remain until everyone is happily using published.
2 Likes
From Blake’s last comment in this thread we understood that he had changed his mind, and we transitioned from master to unpublished for Voice staging, since it looked like any further change would happen at a later stage. Voice production is still using master until the next release which we are intending to do in the course of the next week. We couldn’t know that you and Blake haven’t come to an agreement yet and are still discussing how to proceed. Only a day later then we saw your reply to Blake.
The burden right now is on _publication.json, and we don’t have to do anything.
As this transition wasn’t as easy and went along with a couple of bugs and quite some amount of work we would appreciate not to have to turn it back. This would just add the same work one extra time. So we would like to keep things as they are right now as a temporary stage. As soon as you and Blake have come to a decision and the new publication model has been implemented we will proceed accordingly.
1 Like
Absolutely. The Voice transition to the published branch will start when the published branch is fully functional. We’re just stopped in the no-parking red zone of unpublished, waiting for the light to change. At that time, I suggest that suttacentral/bilara-data make the default branch “published” so that will be what everybody sees.
2 Likes
Okay, so the good news is that we have a published branch, and are starting to populate it. Not ready for use yet, but getting there.
2 Likes