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.

[jpco]

Idea: compromise between 0.9.3 and 1.0 by releasing 0.10.0.

I think it's generally agreed that enough has been changing lately that a bigger bump than just 0.9.3 is warranted. At the same time, I personally still don't think that es is quite "complete", and would love to not have to commit to total backwards compatibility just yet.

I also think that more attention doesn't necessarily need a 1.0 release (consider http://0ver.org/ for examples :) What es more desperately needs to get more attention is, IMO, more yelling about how neat es is. I've been meaning to write blog posts in this vein, but that kind of stuff isn't entirely natural for me.

That said, what needs to be done before 1.0? I don't have a precise list in mind, but at the very least, fixes for closure exports. Lots of the other "classic problems", like tail recursion or extensible parsing, aren't exactly bugs and should be doable without breaking changes. That said, if we want to commit to "backwards compatibility" then we should also think a little about what that exactly means, and we should figure out how we'd want to cover these sorts of desired enhancements; for example, how would we want to handle a change like #210 post-1.0? Would we want to allow changes to $&time as long as it doesn't mess with %time (which might break more people), or would we add a $&time2 (which would bulk up the shell)? Or would we want "pluggable" primitives to allow people to opt into changes in a more controlled way? Or is that even crazier?

I'm just blathering now, but it might be good to answer these questions before the fact.

[memreflect]

Idea: compromise between 0.9.3 and 1.0 by releasing 0.10.0.

I think it's generally agreed that enough has been changing lately that a bigger bump than just 0.9.3 is warranted. At the same time, I personally still don't think that es is quite "complete", and would love to not have to commit to total backwards compatibility just yet.

Agreed.

I also think that more attention doesn't necessarily need a 1.0 release (consider http://0ver.org/ for examples :)

Thanks for the laughs! :)
I agree that 1.0 isn't a necessity.
Elvish is a good example: at v0.21.0, it's a considerably more active project compared to es today.

What es more desperately needs to get more attention is, IMO, more yelling about how neat es is. I've been meaning to write blog posts in this vein, but that kind of stuff isn't entirely natural for me.

Keep in mind that the word "blog" is truncated from "weblog", which is exactly what it sounds like: a log on the Web, and logs are great for a lot.
For example, you can't track iterations of different designs for a concept with Git alone (not easily anyway), but reviewing what worked and didn't work and even expressing complaints is when a log is a perfect tool to informally track progress of an idea without constraining your thoughts to a specific implementation.

That said, what needs to be done before 1.0? I don't have a precise list in mind, but at the very least, fixes for closure exports.

There's another issue with closures, specifically top-level writable closures in initial.es sharing a common set of variables because those closures because their bindings don't reside in GC space.
This is sort of a known problem documented in the "0.79 to 0.8" section of CHANGES, and i've been a bit too busy to examine possible remedies.

Lots of the other "classic problems", like tail recursion or extensible parsing, aren't exactly bugs and should be doable without breaking changes. That said, if we want to commit to "backwards compatibility" then we should also think a little about what that exactly means, and we should figure out how we'd want to cover these sorts of desired enhancements; for example, how would we want to handle a change like #210 post-1.0? Would we want to allow changes to $&time as long as it doesn't mess with %time (which might break more people), or would we add a $&time2 (which would bulk up the shell)? Or would we want "pluggable" primitives to allow people to opt into changes in a more controlled way? Or is that even crazier?

I'm just blathering now, but it might be good to answer these questions before the fact.

These are good questions that deserve consideration, and i have asked myself some of the same ones.

Backward compatibility is a constraint, but it's also a promise, and broken promises would only hurt es.
If such changes to $&time are backward-incompatible, then i would say it should be a new $&time2 primitive, and $&time should be deprecated if $&time2 can do everything that $&time does.
That said, from a SemVer perspective, backward compatibility pre-1.0 is merely a courtesy.

The idea of "pluggable" primitives is interesting; it would be nice to be able to create one or more custom math primitives to allow basic arithmetic in my own shell scripts, perhaps even a module system for namespacing reasons at some point in the future.

It might also be worth examining the current set of "primitives" to determine whether they're doing too much.
For example, $&openfile, $&close, and $&dup all exist, yet they also execute commands?
Why isn't unwind-protect used in %openfile (should that be %open-file?), %close, and %dup instead?

Oh, blather...