Closed tajmone closed 3 years ago
Good catch, @tajmone! I thought about it a while back but then forgot again ;-(
There are no changes on the alfa-branch that should not be part of the beta8 documentation. So we should be good to just merge the alfa changes into the beta-branch (which is master
at this point).
Do you want me to do that? I don't mind, but I probably have to google a bit about merging and keeping the alfa branch live... Could be educational ;-)
There is also another branch about changes to Chapter 5. Although there are tasks left to do there, perhaps the changes already done would be worth merging, so that they don't go stale or causes conflicts later. What do you think?
Do you want me to do that? I don't mind, but I probably have to google a bit about merging and keeping the alfa branch live... Could be educational ;-)
Ok, so we should probably do a local rebase of the alfa branch onto master first and resolve any conflicts there. Then a simple merge from master will result in a fast-forward. And the branch should still exist, it's just GitHub that offers to delete it in the case of PRs.
Is that right?
Do you want me to do that? I don't mind, but I probably have to google a bit about merging and keeping the alfa branch live... Could be educational ;-)
As you wish, I could find some time in the afternoon and to it fairly quickly — we only need to merge the alpha-dev branch into master (without a merge commit, i.e. no using the --no-ff
option), unless you were planning to squash all the changes into a single commit.
I've just rebased all the dev branches and PR branches on the latest master head, as well as updated the published branch for the website (a few docs benefited from updating).
The thing is that the alpha-branch should then become Beta9, correct? since after the merge it would be cover dev snapshots for the next Beta, which is going to be Beta9. Correct?
There is also another branch about changes to Chapter 5. Although there are tasks left to do there, perhaps the changes already done would be worth merging, so that they don't go stale or causes conflicts later. What do you think?
I don't remember exactly what the changes are, but I believe they are rather small and should not cause future integration problems (I've just rebased the PR branch on master, and there were no conflicts). If you're happy with is current changes, you could just squash them into a single commit, force push and manually cherry pick the changes, so we can leave the PR open with all the pending tasks, yet prevent conflicts in the future.
Then a simple merge from master will result in a fast-forward. And the branch should still exist,
Exactly, the trick is to avoid using the --no-ff
merge option (which on GitHub WebUI is the default)!
In the past hours I've been updating ALAN Docs, so all branches were rebased on master.
Right now I'm working on a massive change to the StdLib repo (migration to Rouge), after I finish with this I can handle the MANAUL merge if you like (a bit tired though, might make mistakes).
I'll take care of the merge and publishing of the new Beta8 manual a bit later today (probably).
The thing is that the alpha-branch should then become Beta9, correct? since after the merge it would be cover dev snapshots for the next Beta, which is going to be Beta9. Correct?
Yes. The first commit on the alfa branch after the merge should be to change version designation to Beta9.
I'll take care of the merge and publishing of the new Beta8 manual a bit later today (probably).
Great then. I'm about to finish the massive update to StdLib, and I'm just checking that all the docs have been updated after having deleted various folders and changed the toolchain (that's the hard part, since old details might slip through and end up with out of synch docs). When I finish and push, I think I'll take a break from the PC.
Done.
@thoni56, although ALAN 3.0Beta8 was already released, the Beta version of the ALAN Manual is still marked as Beta7.
We should update the ALAN version, possibly after merging the alpha-dev branch (which should contain only changes that are now part of the latest Beta, unless you kept editing it beyond Beta8).
I vaguely remember us discussing this, but I believe you have a better view of the current state of the alpha branch than I have, for I've been mostly working only on the Beta version of the manual, on
master
.We should really handle this as soon as possible, to prevent that the alpha dev branch starts to describe features which are not part of Beta8,