Release v4.0.0

[josephfrazier]

Hey @slevithan, thanks for giving me commit access in #204 (comment)

Do you think we could go ahead and release/publish v3.3.0 in order to make XRegExp.tag available to npm users? I've modeled the commits in this PR after 5b974aa and ddf24c5, so I'm hoping all that's needed to do is:

• Rebase/merge this PR
• Tag the resulting commit as v3.3.0
• npm publish

Ideally, the website would also be updated, but I'm not sure if/where the source code for that is available, so I can't make any changes there at the moment.

EDIT: This should also fix #198

[slevithan]

I'm down with using the current state as a new release to get XRegExp.tag and a fix for #198 out the door. It should be v4.0.0 though (instead of v3.3.0), since a bunch of changes have been made since v3.2.0 to drop ES3 support for the first time (along with the introduction of XRegExp.tag, the first feature that doesn't work in ES3). Dropping ES3 support is long overdue and hopefully won't affect real users, but it's still appropriate to treat this as a breaking change.

Note that this would be releasing tag with known bug #192. I'm okay with that since we can always do a bug fix follow up.

Apart from the changes in your commits, it would also be nice to add XRegExp.tag to README.md. A possible description to go along with an example (feel free to improve):

XRegExp.tag does more than just basic interpolation. For starters, you get all the XRegExp syntax and flags. Even better, since XRegExp.tag uses your pattern as a raw string, you no longer need to escape all your backslashes. And since it relies on XRegExp.build under the hood, you get all of its extras for free. Leading ^ and trailing unescaped $ are stripped from interpolated patterns if both are present (to allow embedding independently useful anchored regexes), interpolating into a character class is an error (to avoid unintended meaning in edge cases), interpolated patterns are treated as atomic units when quantified, interpolated strings have their special characters escaped, and any backreferences within an interpolated regex are rewritten to work within the overall pattern.

You're right about the remaining steps for publishing. Should be easy like you said, though I might get to the website updates later. It's pretty silly that I don't have a better system for the docs, or at least have the docs in the repo so others can help with updating them. Right now the code for them is fairly messy, though.

Here's a fuller list of changes that can be needed with new releases:

• Version number
  • Update version number and year in headers, config files, README.
  • Update year in LICENSE.
  • Update version number in XRegExp.version.
• Generated files
  • Generate updated xregexp-all.js.
  • Add new xregexp-all.js to tests/perf/versions/ and update the list of versions selectable via query param in perf tests index.html.
• Publish
  • Publish new git tag. E.g.:
    • git tag -a v3.1.0 -m "Release 3.1.0".
    • git push origin v3.1.0.
  • npm publish.
• XRegExp.com
  • Update docs on xregexp.com.
  • Update version history on xregexp.com.
  • Update version number and links on xregexp.com.

[josephfrazier]

It should be v4.0.0 though (instead of v3.3.0), since a bunch of changes have been made since v3.2.0 to drop ES3 support for the first time (along with the introduction of XRegExp.tag, the first feature that doesn't work in ES3).

Good point, I had forgotten that we've dropped ES3 support, and I agree that it's a breaking change. Do you still want to also get #89 into v4.0.0 (see #89 (comment)), or can it wait until v5.0.0?

Apart from the changes in your commits, it would also be nice to add XRegExp.tag to README.md. A possible description to go along with an example (feel free to improve):

Agreed, I'll open a PR with the example you suggested, and think about potential improvements.

You're right about the remaining steps for publishing. Should be easy like you said, though I might get to the website updates later. It's pretty silly that I don't have a better system for the docs, or at least have the docs in the repo so others can help with updating them. Right now the code for them is fairly messy, though.

No worries on the code being messy! I'm just happy to hear that it doesn't have to be updated alongside a new release.

Here's a fuller list of changes that can be needed with new releases:

Thanks for listing these out, it'll be useful for reference in the future.

[slevithan]

Thanks, Joseph. Other breaking changes can wait until v5.0.0, in the interest of not delaying this further. I'm fine with breaking changes coming in rapid succession, BTW, whenever they're ready, assuming they are substantial/worthwhile changes like #89.

Not directly related, but FYI: I've usually avoided introducing regex or replacement text syntax changes except in major versions (x.0.0), even when they aren't breaking changes. This is because of tools like RegexBuddy that need to reference/emulate multiple versions of XRegExp syntax. I know the author of RegexBuddy would prefer not to have to differentiate between syntax in minor versions.

[slevithan]

Other breaking changes can wait until v5.0.0, in the interest of not delaying this further.

I guess it would be nice to roll #89 into v4.0.0, since you already have a pull request for it almost ready to go with #207.

[josephfrazier]

Great, thanks for the additional info about the breaking/syntax changes, I'll try to keep those points in mind. Once we land #207, I'll update this PR.

[slevithan]

Tagged and published as v4.0.0.

[josephfrazier]

Yay, thanks!