Let’s give it a try on Monday.
11 Likes
Has the switch been delayed again? It still targets to JuliaRegistries/Test:
There’s still an awful lot of Monday left in the USA.
14 Likes
Now that the version number in “Project.toml” will have a lot of practical impact: What’s the best practice recommendation regarding management of the version number? Should the version number be increased
- Just before registering a new release?
- Just after registering a new release?
- Continuously throughout the development process between releases, i.e. a minor version number increase after (or before?) the first bugfix, a major one after (or before?) the first breaking change, etc.?
1 Like
Doesn’t really matter, but note that the second option does not work since you need to have the correct number in the project file when releasing. The approach I have seen used the most is to increment it just before releasing, and make the “bump version” commit the commit that you tag for release. (See also What should version in Project.toml be between releases? · Issue #351 · JuliaLang/Pkg.jl · GitHub for some old discussion.)
3 Likes
Indeed. We’ll switch in the evening since so that it’s morning in India where @Nishanth_Kottary is.
6 Likes
To help out with the switchover, I’ll be taking attobot down now. I’ll bring it back up tomorrow, but it will only support releases for Julia versions <= 0.6.
6 Likes
Update: Registrator is now switched to General
17 Likes
https://github.com/JuliaRegistries/General/pull/33
Haha 
It doesn’t seem to be responding to my comments since you switched it to General. Could this maybe be because I have out-standing PRs open against the Test Registry?
EDIT: or maybe it’s overwhelmed with API calls? I would believe that 
2 Likes
Registrator is responsive. This is my case: https://github.com/bicycle1885/TranscodingStreams.jl/issues/80
2 Likes
Ah yeah i just saw your PR as well. Hmm, maybe it is indeed because I already have an open PR from earlier today when I tried to register before the switch to General was made 
@NHDaly It seems your browser is sending some extra characters in the register() call. This should be fixed in Registrator by trimming which I will do later today. I see that your previous register()s went through. Did you switch to a different browser by any chance?
1 Like
Huh! No, i didn’t, but the first one I typed by hand, and I think all the rest I’ve been copy/pasting! I’m on the latest Chrome (73.0.3683.103) on the latest macOS (10.14.4 (18E226) ).
Damn, I’m sad, I was hoping to have the first PR in the door. 
But thanks for the explanation!
1 Like
The switch is done! Several dozen PRs to register new packages and new package versions have been merged this morning and everything seems to be going well. For now the merge process is manual (I take a look at it and merge it if it looks sane. In the near future, we will implement automatic registration PR merging for PRs that pass a reasonable smoke test.
One thing there are some issues with are the instructions that get posted in on the original commit for tagging a release. Specifically, the instructions tell you to tag a tree hash, but that’s not how things are normally done in git/GitHub. The git CLI supports tree tags, but GitHub, not so much. Registrator will be updated to post instructions for tagging a commit instead of a tree soon.
19 Likes
Hooray! Thanks again for the work on this!! 
!
I have switched attobot back on, but it will now only tag packages which are enabled for Julia 0.6. Please open an issue if it doesn’t work, as I haven’t actually tested it.
6 Likes
I tried Registrator.jl for the first time but my PR isn’t being merged: https://github.com/JuliaRegistries/General/pull/77
It looks like other PRs are merged within an hour. Is there something wrong with the way I made the PR?
The merging process is manual for the moment, so the “problem” is that Stefan is sleeping I guess 
3 Likes
Ah, that explains it. Sounds like a blast 
I’m a bit confused: I tagged FillArrays.jl v0.6 using the new procedure, but this is prevented by use due to upper bounds in JuliaRegistries/General in BandedMatrices.jl (https://github.com/JuliaRegistries/General/blob/master/B/BandedMatrices/Compat.toml), LazyArrays.jl, and probably a few others. I have no idea where these upper bounds came from: they were added on 11 April by a sync from METADATA.jl, but The upper bounds aren’t present: BandedMatrices.jl only has a lower bound for FillArrays.jl (https://github.com/JuliaLang/METADATA.jl/blob/metadata-v2/BandedMatrices/versions/0.9.0/requires).
Any idea where these upper bounds came from? Any suggestion other than re-tagging everything?