Create a release tag (latest version) about lz-string HOT 11 CLOSED

+1

from lz-string.

+1

from lz-string.

Ah, I see I forgot to update the issue. I've created a while ago several subdirectories under libs to show the different versions of the lib available. One of them is release. Let me know if it makes sense for your needs. I'll close the issue shortly if everything is ok.

from lz-string.

For smooth integration with bower, an actual release number is needed.
Github makes it very easy. Check this out:
https://help.github.com/articles/creating-releases/

I suggest you move the older stuff into separate branches, if their code isn't required for the release version.

from lz-string.

There you go. I still need to do some cleanup to - for example - remove the version number from the file in libs/release.

from lz-string.

Is there anything else to do here? If no one responds I'll close the issue shortly.

from lz-string.

Well, I ran bower update using the 1.3.3 release tag. The folder structure changed now, so anyone who used the previous github hashtag will now have to update their references... not the end of the world, but breaking backwards compatibility nonetheless.

Honestly, I see no reason to keep the "beta" and "oldStuff" folders. As well as older versions of lz-string (release/base64-string-v1.1.0.js). That kinda misses the whole point of release tags. the older versions should move into relevant branches (with their own release tags). The "libs" folder should simply contain lz-string-1.3.3.js and lz-string-1.3.3.min.js. And that's it. I can do it myself if (fork and push) if you'll agree :)

from lz-string.

Does it mean I will have to keep the libs/release/lz-string-1.3.3-min.js file forever? Not necessarily a big deal, but I need to know before I move stuff around ;-)

BTW, base46-string is another lib, not an old version.

Also, the version 1.1 is the implementation reference version, used mostly to have the algo in a readable file. 1.3 has been optimized for the various JS engines out there and is - for the most part - unreadable.

from lz-string.

Well, a quick and dirty solution will be to simply move lz-string-1.3.3.min.js and lz-string-1.3.3.js into /lib, and put the reference files in their own folders inside lib, so at least backwards compatibility won't break. I still believe the "reference files" should be moved into other branches. If you need to use the older reference version - then you should simply check out that specific version.

Unused code shouldn't exist in a branch.

As for the min file being kept forever - I believe the proper solution is to create a build process with grunt that minifies lz-string-1.3.3, and run that script whenever you commit and release a new version.

from lz-string.

Ok, I moved stuff around. I feel like backward compatibility is important but I couldn't get myself around leaving all those directories and files around, sending the wrong message. Also, too many "arounds".

I've also released two new versions. Let me know if everything works out for you.

As for the min file, well, I am closer to having it automated on my end. Both files are available and people can choose the one they want.

from lz-string.

I started using 1.3.5, and it seems to work fine (backwards compatibility was broken though, since the file I include changed from lz-string-1.3.3.js to lz-string.min.js, so perhaps you should mention that in the release notes). Thanks 👍

from lz-string.