Julia: 0.5.x?

[timholy]

In one of my private repos tests pass locally on release-0.5 but fail on Travis, and the failure looks consistent with a difference between what was tagged as 0.5.0 and what's in release-0.5. Are there plans for point-releases of 0.5, or are we going straight to 0.6? If nothing else, any chance we can "bless" what's in release-0.5 now as 0.5.1 and call that good enough?

[tkelman]

What's on release-0.5 hasn't gone through testing, and there are likely as many regressions there as fixes. So please don't code against that in packages as if it's a stable tested release, because it isn't. I've been intending to make a proper 0.5.1 but have been way overloaded.

[timholy]

I should add that it seems useful to be able to check out a branch that means "keep up with the latest official release in the 0.4 series." I've just assumed that's the meaning of the release-0.4 branch. Is there a different branch for that purpose? If not, we might want to clarify the role of these branches (and/or create new ones) for the 0.6 release.

[tkelman]

No. We have -latest binary links for that, but not git references for building from source. If you're building from source I kind of assume you know what version number you want, and specifically when you want to change what you're building?

[timholy]

I may well be in a tiny minority, one that is capable, as you say, of specifying exactly what I want through several different means. But to explain: I'm so used to the git workflow that downloading a binary seems vaguely silly. To me it seems natural to have a branch that is a source-build version of whatever is in the latest binary, but I confess this expectation is not based on standards/experience elsewhere/etc, it's just me making stuff up.

[tkelman]

If you want to update that branch each time a stable release is made I won't stop you, but I'd rather try to make the checklist of things to be done for each release shorter, not longer. There's a script at https://github.com/JuliaLang/julia/blob/master/contrib/prepare_release.sh that we can add steps to if you think you won't be the only one to use such a thing.

[timholy]

Given that currently release-0.5 is ahead of, or different from, "official 0.5 releases," I'm confused about what "if you want to update that branch" means. Maybe I should ask this in a different way: what is the true purpose of the release-x branch? If the name doesn't quite reflect its current purpose, should we consider alternatives?

[tkelman]

Currently it's a staging area for things that are likely, but not guaranteed, to be included in the next release. Anything that's there now that wasn't in a release tag is subject to be reverted if it caused package regressions, which I'm sure a few of the things that are there right now have done.

[timholy]

Gotcha. Naming is hard, but I'd suggest staging-0.5.x for that purpose. release sounds awfully official to me. EDIT: I'm not proposing that x changes for each point-release, I'm proposing that literal string as the name. Useful for people who are willing to be guinea pigs for the stable branch.

[tkelman]

The release branches have been used in exactly this same way for multiple years now. The only thing that's changed is a longer-than-usual delay at the moment between actual release tags.

[JeffBezanson]

Anything breaking on a release-0.x branch is supposed to be extremely rare, and should get reverted as soon as possible. If it's not pretty obvious that a patch is safe for backporting, it should be tested on a different branch first instead.

[tkelman]

Agreed, but there are a number of things on release-0.5 right now that are not obviously safe and have not gone through extensive testing (meaning pkgeval). We ideally need to get to a point where we can trigger pkgeval on a PR on demand, like with nanosoldier. I'm waiting on infrastructure work for that to be possible without having to do the whole thing manually, cc @tanmaykm and @ViralBShah. (and I haven't done it manually on WIP that is incomplete - if I knew people would use unreleased branches as if they were releases, I wouldn't have merged anything yet)

[andyferris]

I agree with Tim that the branch name is unintuitive (and I've been caught out by it).

I understand that you guys may have used this in this way for years, but I feel Tim's suggestion may be more outsider-friendly.

[tkelman]

I don't know of any project that keeps a git branch that only changes when a new release gets made. That's an odd thing to ask for and I'm not especially motivated to rearrange various scripts or CI configurations to accommodate it.

[davidanthoff]

I don't know of any project that keeps a git branch that only changes when a new release gets made. That's an odd thing to ask for and I'm not especially motivated to rearrange various scripts or CI configurations to accommodate it.

gitflow has the master branch only change when a new release gets made, so if one stays on master one is guaranteed to only get released versions. It seems quite a popular workflow, as far as I can tell. I'm not suggesting that julia adopts this, just pointing out that having a branch that only ever has released commits on it is certainly not esoteric, it is at the core of one of the most popular git branching models.

[StefanKarpinski]

People talk about gitflow a lot, but I'm not aware of any major projects that use gitflow and I've never worked anywhere that used gitflow for development either. That may be a peculiar experience, and I may be unaware of some big projects using gitflow, but the best practice seems to be avoiding long-lived feature branches and merging work back to master as often as possible without breaking it.

[davidanthoff]

There are no long-lived feature branches in gitflow. There are two long lived branches in gitflow, develop and master. develop in gitflow is pretty much managed exactly like master in julia right now (there are some subtle differences, but I don't think they are important). If there was another branch in julia that was named say release-latest that was guaranteed to always point to the latest tagged released version of julia, the two branching models would be even more similar, i.e. release-latest in julia would be roughly similar to master in gitflow. Maintaining release-latest would not be that tricky, essentially someone would just have to checkout release-latest after a release has been tagged and then do git reset --hard v0.6.0 (or whatever that release was) and then commit that (it would be nicer if git merge -s theirs still worked, but apparently that was removed from git...).

I don't have a need for something like release-latest because I'm on windows and use the binaries, but if I were a user (and not a julia dev) and on a system where I was mostly build from source, I would find such a branch useful. I guess @timholy falls into that category.

I totally understand that @tkelman doesn't want to maintain another thing, but hey, if @timholy thinks that would be useful, maybe he could just create that branch and "maintain" it? Literally "maintaining" it would amount to something like three git commands after a release is tagged, and I could easily see more people finding that branch useful.

[tkelman]

If it needs to be constantly reset, then you wouldn't be able to fast-forward on it and there's not much use in it being a branch. I also think unversioned -latest isn't a good idea, you shouldn't be getting breaking-changes upgrades automatically unless you specifically opt into that.

[StefanKarpinski]

It seems to me that the only real issue here is that the branch name release-x.y may be misleading.

[ViralBShah]

Yes, I can see how the name is misleading too.

[StefanKarpinski]

On the other hand, it's the branch where the x.y release is maintained.

[timholy]

The original motivation for this was fixed by #20736.