Why?!?
Ok, that got me to try again and I was just clicking on the wrong places. Sorry!
Deleting a release on GitHub is quite annoying, it requires several clicks and you have to delete the associated tag as well, but I was surprised that you can’t delete a release from your own repository.
Right, makes sense; somehow I thought since TagBot had made the release that was why I couldn’t, instead of the simpler explanation that I was just doing it wrong. But I’ve got it sorted out now I think.
Why is this new setup (Registrator + TagBot) better than the old one (attobot) which required just a new tag to do the whole process?
2 Likes
I have to say I find the new system really cumbersome as well… I also think what is really missing is clear guidelines, written in one place, how one is supposed to use this new system, what steps to take to say release a new version etc.
For example, is the idea now that one creates a branch for a potential release, increases version in the Project.toml, then asks Registrator to register that, wait until it is merged, then somehow merge the release branch back into master? Or some other process? It would be really helpful if the creators of this new system wrote down their take on all of that in one place so that package devs don’t have to think about this, figure this out ourselves, but just can follow a best practice system.
1 Like
- Set the
versionfield to your new desired version. -
@JuliaRegistrator register()on the commit/branch you want to release. - If something is incorrect, adjust, and redo step 2.
- Done.
Edit: It is literally the exact same steps as with attobot, with the exception that you don’t have to delete tags/releases when you find an error.
5 Likes
But as I understand, this is just the first part of the process, right? I mean, will Documenter release docs be updated if I do just that?
Nothing has changed with Documenter, that is completely unrelated.
This new process is totally fine with me. I’m just provoking you to think about the whole process and not lose focus. I’ll remember to tag releases just to trigger the Documenter. But I’m an experienced Julia user. I’m afraid others won’t see this. Or maybe I’m just wrong.
With TagBot installed, the new process is super easy. It might have been easier to merge Registrator and TagBot though.
Yea, that was the case at first but then people got butthurt when they had to give Registrator write access to their repos.
3 Likes
The Documenter situation would fit current Registrator workflow (without needing TagBot) if all doc history could be hosted at pkg.julialang.org with deterministic URLs. Package owners would just update docs link to follow pkg.julialang.org URL, and Registrator would trigger docs update at that site. It looks like a part of this is already working.
I think this is the way Rust’s Cargo works.
This is possible but it’s an optional feature of Registrator.jl (I used it so I know it works). But I think you would need to understand that this feature is potentially dangerous because you would break the assumption that Registrator.jl is making if you rebase the branch after the registration is complete. IIUC this is why PR-based workflow (still mentioned in full_readme.md) is currently disabled. See also Zot/bitbucket support by zot · Pull Request #1 · JuliaComputing/Registrator.jl · GitHub
I think the simplest workflow would be to bump version, push it to the master branch, open an issue with @JuliaRegistrator register(). Note that putting @JuliaRegistrator register() in an issue makes sure that Registrator.jl sees the master branch and not any other branches. This workflow may clutter your master branch if you are requested to fix something during the registration process. However, unless you really hate cluttering the master branch, I don’t think you need to go with the branch-based workflow.
Saying “It is literally the exact same steps as with attobot” is pretty misleading.
- Step 1 was optional with attobot. (Just don’t put any version in Project.toml). Instead you just put the version in the github release.
- Step 2 is also completely different, it involved magic comments on a commit/issue/PR. Rather than selecting a commit/branch via a webinterface.
- Step 3 is different (as you said) since befor you had to delete tags and relases when you found an error
- Also without TagBot, step 4 should be “tag and make a github release”.
so that people can actually see that a release has been done on GitHub.
2 Likes
Possibly, but I think that just understanding the new process as is is perhaps easier than comparing with attobot, as the whole thing is pretty simple.
BTW, @ invocations in comments/issues on Github are not “magic”, it is a pretty standard invocation mechanism for bots. I like it very much.
I also love the fact that I don’t have to go through deleting tags/releases when I mess up. I think that the new registry management process is very well thought out and works smoothly.
Sorry, I don’t mean to sound down on it.
It has its pros and cons.
Overall, I feel basically neural about it.
My point was: saying it is exactly the same will mislead people.
Perhaps @fredrikekre meant to say:
“it is exactly as complicated”
BTW,
@invocations in comments/issues on Github are not “magic”, it is a pretty standard invocation mechanism for bots. I like it very much.
I would disagree, bots are magic. Talking to them makes that magic more obvious than them just doing stuff when you make a release.
1 Like
I didn’t find attobot complicated, and I find the new mechanism simpler. YMMV.
My point was that given how simple the process is, it can (perhaps should?) be understood without comparison to attobot.
While I was able to infer and figure out the process from the information available, I know there are many other users who will have a hard time because the instructions are not clear enough (for example for older or less technologically savvy people, who may not be inclined to research the processes)
Having an extremely clear description with examples of Project.toml and precise details (not on discourse but in the relevant place) would help clear things up for the confused people.
1 Like
If you can be more specific, perhaps you could make a PR to the README of