Releasing 0.9.3? 1.0?

[wryun]

How do people feel about releasing 0.9.3?

Or perhaps we should be trying for a 1.0 just for fun? Is there anything that 'should' be in 1.0?

[jpco]

Glancing at what changes have come around since 0.9.2, I'm realizing that #41 was merged less than two weeks after 0.9.2 was cut, and has just been sitting around, unincluded in any actual release, for two years! IMO, that change is such a significant improvement to the experience of using es that it alone justifies a new release.

In addition, since 0.9.2, we've got:

• match (Add switch statement #36)
• Better readline completion support (Add readline completion for variables, primitives, and usernames prefixed with ~ #59, Quote files which contain '. #74)
• Portability improvements (Use esopt() for option parsing in main #61)
• Several fixes for memory bugs and other "non-graceful exit events" (Fix bugs revealed by GCDEBUG. #52, Fix some bugs that weren't previously reported #58, Fix syntax-handling bugs #69, Root exceptions during the varpop() calls in throw(). #86, Fix error handling for scanerrors at end of line #94, Ref() the -c command string #95, Fix panic when trying to eval concatted prims. #96, Fix ^\ handling with readline, without breaking ^D handling with readline. #116, Do not die when reading incomplete heredocs #118)
• Small behavioral changes which could be considered bug fixes (Clear eval_exitonfalse when setting up a new input stream. #119, Return true instead of the new PID from %background #122)

The only reason I can see to wait before putting out another release is to get some of the outstanding pull requests merged. The range of open PRs #120-#129 seem worthwhile for building and running portably and #130 seems like a relatively clear bug fix.

As far as 1.0 goes, it's an interesting idea. What would releasing 1.0 mean?

[wryun]

Re 1.0, I think it's mostly a marketing: a claim that es is stable and feature complete enough that you should feel comfortable using it. There's also the 'match' funciton, which seems a large enough change that it would deserve a new semver minor version if we were actually using semver.

It would also make me more comfortable with larger changes - i.e. having released a '1.0' we could then try #79 in a 2.0 branch, or even just be happy that a conservative 1.0 was released before everything changed.

[memreflect]

Semver basically says you can do anything you want prior to v1.0.
Once you release v1.0, you're bound by compatibility guarantees, which is the entire point of semver:

• bug(s) fixed without a significant impact upon existing features (e.g. fixing a memory leak)
  • v1.0.1 -> v1.0.2
• backward-compatible feature changes (e.g., a new primitive or setting history = filename 1000 now limits the in-memory history list to 1000 entries)
  • v1.2.2 -> v1.3.0
• backward-incompatible feature changes (e.g., dropping $&pathsearch and replacing it with $&access in %pathsearch)
  • v1.5.0 -> v2.0.0

If es wants to use semver, then i'm not confident that es is ready for v1.0 yet, but v0.9.3 is reasonable enough considering the number of changes that have occurred since v0.9.2.
Otherwise, v1.0 could be released with v2.0 being the true "semver" release or whatever, if that's desirable at that time.

[pmarreck]

Not to be undersold is the possible attention (assuming one wants that) that a 1.0 release might garner from the fellow nerds at large. This might also include possible future contributor attention as well.