Request - version bump on js files or revert master

[jvanasco]

Preface: I know this project is not maintained any longer.

I'm looking to upgrade to the new non-jquery version and checked to see if there were any fixes since the 1.4.1 release I have in the interim.

I noticed that these lines still reads 1.4.1 -

• https://github.com/carhartl/jquery-cookie/blob/master/src/jquery.cookie.js#L2
• https://github.com/carhartl/jquery-cookie/blob/master/bower.json#L3
• https://github.com/carhartl/jquery-cookie/blob/master/component.json#L5
• https://github.com/carhartl/jquery-cookie/blob/master/cookie.jquery.json#L3
• https://github.com/carhartl/jquery-cookie/blob/master/package.json#L3

Since this project is essentially shut down and the commits since 1.4.1 won't be integrated, I wanted to suggest either:

• Roll "master" back to the 1.4.1 release (the current master can be a working version or something)
• Update the 1.4.1 release number in master to 1.4.2-dev or 1.4.2-unreleased

[FagnerMartinsBrack]

I don't understand exactly what is the problem. 1.4.1 is the latest release for jquery.cookie. js-cookie started from js-cookie/js-cookie@4527b37 up to the version 1.5.0, which contains everything this repo has, except the notices.

• The problem with hard reset is that it will break forks.
• Releasing a new version doesn't seems to make sense because everything here is contained in the version 1.5.0 anyway.

Btw, the master branch should not be used in production because it is, by default, an unstable branch. The only version that should be considered here is the ones that were released up to 1.4.1.

[jvanasco]

I'm not suggesting a new release. I'm suggesting that either the "master" branch of this project roll-back to the 1.4.1 release, or that the files be tagged "1.4.2-dev" (but no new release made).

The reason is because the master branch is not actually "1.4.1" -- it has a lot of commits since then, but the repo's design makes it look like master is 1.4.1. I

[FagnerMartinsBrack]

The reason is because the master branch is not actually "1.4.1"

Now I got it, it can be confusing for people that copies the code directly from the source without checking the releases page. Is that it?

[carhartl]

So you expect the master branch to practically match a release, like in the git flow model?

[jvanasco]

@FagnerMartinsBrack yes. If someone looks at this repo and says "ok, let's just see what the last update here is..." then looks at the file, they get the unreleased version not the actual 1.4.1

@carhartl I'm a fan of that model, but not expecting it. Many projects might use a "-dev" or other placeholder version in their master branch, or bump the version number up to the forthcoming release. This repo is weird/misleading because there is a "1.4.1" tag, but the "master" branch used for development has files labeled "1.4.1" as well. It suggests that the master and the tag are the same, but master is many commits ahead.

[FagnerMartinsBrack]

I am convinced that changing the version number to 1.4.2-unreleased or 1.4.2-frozen for all relevant files in master (without publishing it on npm) is a reasonable request to prevent further confusion.

@carhartl what do you think?

[FagnerMartinsBrack]

@jvanasco sorry to take too long, here is the Pull Request, care to take a look?

[carhartl]

I still haven't unterstood up to this day what the problem is.

[FagnerMartinsBrack]

I still haven't unterstood up to this day what the problem is.

Basically if he goes to the Releases page it says:

39 commits to master since this release

This will make one to assume that there were additional important fixes on this repository after 1.4.1 which weren't released with 1.4.1. We know it is not the case and all commits went to the new repo, but those ending up here don't know that. Since most people jump straight to the version in the source file or json metadata to check the actual version, 1.4.2-unreleased provides a clear hint that the commits belong to a non released version 1.4.2.

Other solution is to create an actual new 1.4.2 release and publish on npm so that master is not too far away from the latest release.

@jvanasco please correct me if I am wrong.

[FagnerMartinsBrack]

@carhartl @jvanasco I will leave #388 open, if there is no feedback for a few days I will just merge it to close this issue, then we can monitor if anybody else will have this kind of problem in the future.

Does that makes sense?

[jvanasco]

Looks good.

That's a good distillation of the confusion.

Also, If you search online for the latest version, you'll end up seeing the current master which is really "1.4.2-unreleased" and not 1.4.1 as labeled. So it can be confusing to see what version is really running -- especially if junior devs are checking in the file.

On Mar 4, 2016, at 6:12 AM, Fagner Brack notifications@github.com wrote:

I still haven't unterstood up to this day what the problem is.

Basically if he goes to the Releases page it says:

39 commits to master since this release

This will make one to think that there were additional important fixes on this repository after 1.4.1 which weren't released with 1.4.1. We know it is not the case and all commits went to the new repo, but those ending up here don't know that. Since most people jump straight to the version in the source file or json metadata to check the actual version, 1.4.2-unreleased provides a clear hint that the commits belong to a non released version 1.4.1.

Other solution is to create an actual new 1.4.2 release and publish on npm so that master is not too far away from the latest release.

—
Reply to this email directly or view it on GitHub.

[FagnerMartinsBrack]

It seems this s going nowhere, as from this comment.

I have added the following to the version 1.4.1 in the releases page, I hope this at least clarifies for those who don't read the README and go straight to the releases page:

Note:
This is the last version on this repository. To see all the versions, check the new repository.

For more information, see this comment.