Figure out how we are going to tag jQuery Compat releases

[mgol]

Now that version numbers will match 3.0.0 will not suffice.

[mgol]

cc @jquery/core

[dmethvin]

Hmmm. Good question. I guess it could be 3.0.0-compat or something?

On a similar note, the value for jQuery.fn.jquery will also need to be unique, that could be 3.0.0-compat as well I suppose. We already put stuff after the version number when it's a custom build.

[mgol]

I guess it could be 3.0.0-compat

On a similar note, the value for jQuery.fn.jquery will also need to be unique, that could be 3.0.0-compat as well I suppose.

:+1: to both; people need to be able to distinguish between them programatically.

[scottgonzalez]

With a new name and matching versions, I'd suggest it's time to move to a new repo instead of continuing to use a branch.

[mgol]

On Friday, November 14, 2014, Scott González notifications@github.com wrote:

With a new name and matching versions, I'd suggest it's time to move to a new repo instead of continuing to use a branch.

We'd then have separate bug trackers/pull requests for both repos and due to how much code is shared between branches that wouldn't be desired IMO.

Michał Gołębiowski

[scottgonzalez]

Separate bug trackers and pull requests is actually a good thing. They do share some bugs, but there's no denying that they have separate bugs, and they already need separate pull requests.

[mgol]

They do share some bugs

At first glance they actually share about 90% of them.

they already need separate pull requests

That's true.

[dmethvin]

There's a lot of common code, we can generally cherry pick things across without conflicts. That's why I'd prefer to have one repo and two branches.

[markelog]

Git can cherry-pick from different repos. Different repos or different branches conflicts are always possible.

[markelog]

At first glance they actually share about 90% of them.

We could mention issue from different repository in the commit & pull-request. But still :-(

[timmywil]

they already need separate pull requests

This actually isn't true most of the time. Usually, we just cherry-pick the squashed commit onto 1.x-master/compat rather than force separate PRs. There are occasions where the changes are big enough to beg separate PRs, but we're often the ones making those kinds of changes.

Anyway, I prefer one repo too.

[mgol]

@timmywil I've understood it as a trivial observation that a PR cannot target both branches at the same time. I agree most of the time we can cherry-pick unless we're doing sth in a rewritten module or we're touching a lot of code.

As for tagging - does jquery-release need an update to be able to tag 3.0.0-compat? The rest should be simple.

[dmethvin]

True, the PR can't target two branches but as @timmywil says it's often pretty trivial to cherry pick without a PR. I usually just get hung up on the differences in the internal .data() implementation, and I hope we can fix that in 3.0.

[scottgonzalez]

As for tagging - does jquery-release need an update to be able to tag 3.0.0-compat? The rest should be simple.

It will need more than just an update to how it tags, since everything is based on x.y.z versions. Keep in mind that 3.0.0-compat in semver means it's a pre-release of 3.0.0.

[dmethvin]

We can use build metadata? 3.0.0+compat

[mgol]

Keep in mind that 3.0.0-compat in semver means it's a pre-release of 3.0.0.

If we're going to keep both branches in the same repo (and it seems most of the team favors that solution) tags will not have to be semver versions anyway. If we want to make it clear it's not semver we can always tag it compat-3.0.0 I guess.

[mgol]

Hmm, I've just realised one repo & the same versions won't most likely fly with bower...

I dislike that we have to support both npm & bower now. :/

[dmethvin]

Wouldn't there be two packages with bower as well?

[scottgonzalez]

Wouldn't there be two packages with bower as well?

two packages = two repos

[mgol]

Wouldn't there be two packages with bower as well?

Yes, but bower is tied to repositories so it'd have to be pointed at jquery/jquery. And it takes versions from tags which means we'd have to use 3.0.0 for both jquery and jquery-compat which is impossible.

[timmywil]

Ok, yea, bower does require separate repos for multiple components. Maybe that clinches it.

[mgol]

two packages = two repos

It seems we don't really have a choice then... We could still disable issues in jquery-compat so that it all gets kept in one place (PRs are OK); our local compat branches can track master on jquery-compat (we can also make compat the main branch on jquery-compat to reduce confusion).

[dmethvin]

Bower needs it for distribution. We don't need to develop in it, do we?

[timmywil]

Bower needs it for distribution. We don't need to develop in it, do we?

That's true, I suppose. We do have the option of pushing only the compat distribution to the separate repo.

[mgol]

We do have the option of pushing only the compat distribution to the separate repo.

That will most likely be quite difficult to achieve with jquery-release unless we just push the compat branch to a separate repo as well. But such duplication would be confusing for outsiders; I'd rather have it in one place.

[timmywil]

That will most likely be quite difficult to achieve

I don't think it would be difficult enough to write it off.

But such duplication would be confusing for outsiders

Outsiders are already confused, but we wouldn't be the only ones with distribution-only repos.

[markelog]

Outsiders are already confused, but we wouldn't be the only ones with distribution-only repos.

Who else is doing that?

[dmethvin]

Isn't that the way jquery was in Bower before we took it over?

[timmywil]

The more I think about it, the more I prefer this option. None of us want to spend our time migrating issues from one repo to the other or creating duplicate issues in cases where they affect both. That means we'd probably want to disable issues on the compat repo, but that's problematic. I don't think it's possible to auto-close issues on another repo (i.e. our commits to the compat repo wouldn't auto-close issues on the master repo). There's just much more overhead that comes with two development repos.

[mgol]

Isn't that the way jquery was in Bower before we took it over?

Yes, the whole https://github.com/components org is for that. Those modules are not managed by owners, though.

One example is Angular, there is https://github.com/angular/bower-angular etc. (funnily enough, this repo is now publishing to npm as well).

[timmywil]

Who else is doing that?

Off the top of my head, I can think of Angular and lodash.

[mgol]

I don't think it's possible to auto-close issues on another repo

It is: https://help.github.com/articles/closing-issues-via-commit-messages/#closing-an-issue-in-a-different-repository

We'd have to write Fixes jquery/jquery#42, though.

[dmethvin]

I actually like the idea of separating our development repo from the distribution repos. Mixing the two always seemed icky.

[mgol]

I actually like the idea of separating our development repo from the distribution repos.

Would you also want to separate jquery bower distribution repo?

Mixing the two always seemed icky.

It does but we already have a process for that with jquery-release.

[markelog]

Isn't that the way jquery was in Bower before we took it over?

There was a different reasons for that, but i see your point, if it's not uncommon or weird, or moreover preferable, than i think it's good way to go.

btw, i guess github is now a replacement for #jquery-meeting channel huh :-)

[timmywil]

btw, i guess github is now a replacement for #jquery-meeting channel huh :-)

ha, or email.

[markelog]

Off topic and pretty much crazy - maybe we should use github for meetings? Like create special repo and use issues for meetings?

[timmywil]

Off topic and pretty much crazy - maybe we should use github for meetings? Like create special repo and use issues for meetings?

No.=

[dmethvin]

Well this is a bit of an exception, and a little more chatty than we typically do. Still it's good to have discussions somewhere to make progress and we've missed a few meetings lately. :beers:

[markelog]

No.=

:-)

[mgol]

TBH an ideal solution to me would be to:

1. have separate repos for bower jquery and jquery-compat packages
2. not create detached tags on jquery/jquery, npm can handle non-detached ones easily (in fact, it doesn't care about tags or git at all when publishing)

That said, every such change would affect jquery-release in a way so we probably need to have "a good reason" for everything.

[dmethvin]

@mzgol I agree separate repos for distribution seems like the best approach. Our development repo isn't in a position where you can just pull from it without a build process anyway. It seems like we'd want to publish both bower and npm from these new repos.

Any arguments against this approach?

[mgol]

@dmethvin We still need to figure out how to integrate it all with the jquery-release process.

[timmywil]

@mzgol Let's cross that bridge when we come to it. Unless other projects want to do things this way, we may not need to change anything in jquery-release. We'd use what we can and take it from there in our own release.js. Regardless, I think this particular issue has resolution. I've opened a new one for implementing the distribution process.

[mgol]

Regardless, I think this particular issue has resolution.

I think we still want tagging on the original repo (regardless where we release to bower/npm from) so we need to settle on a tag. Is 3.0.0+compat OK for everyone?

[timmywil]

3.0.0+compat

:+1:

[dmethvin]

Works for me. As I understand the oracle at semver.org, the beta1 version for a compat build would be something like 3.0.0-beta1+compat which is a mouthful but as long as it works I'm good with it. In reality I don't think that will cause confusion because there are two different distribution repos.

[mgol]

As I understand the oracle at semver.org, the beta1 version for a compat build would be something like 3.0.0-beta1+compat which is a mouthful but as long as it works I'm good with it.

We need to ensure we account for that, it's way too easy to append these prefixes in the wrong order (unless we can just use the npm semver package to do this work for us).

In reality I don't think that will cause confusion because there are two different distribution repos.

Yes, but, as I mentioned above, we're still need to tag branches on the original repo so sth had to be decided.

[mgol]

I thought about it and I think 3.0.0-beta1+compat looks weird as it seems as a compat build of the 3.0.0-beta1 version and they definitely don't have to match unless we always plan to release all betas/patch releases at the same time for both branches but we don't want to rely on that, do we?

I'm reopening the issue since we're still discussing it.

[timmywil]

I don't think that's a real issue. First of all, it doesn't really matter what we tag it. It will not be for public consumption. So, we are the only ones that need to know that 3.0.0-beta+compat only refers to the 3.0.0-beta version of the compat branch, independent of master. Second, unless someone offers up a better option, let's consider this resolved.