2.1 development put on hold?

[Adventurer]

Up until recently, 2.1 has been receiving updates in parity with the fixes and changes made to the release version. Now it's two or three versions behind (two I think) and the one before that didn't receive its parity update until much later.

Just curious as to what's going on and what the plan is.

[lexikos]

[Adventurer]

Uh... okay... sorry, I guess.

[lexikos]

I didn't take the time to reply because the reason I opened the forum was to release v2.1-alpha.10.

Seriously though, there are only so many hours in the day. It takes time to document changes, even just bug-fixes, and make the release actually work. For v2.0.13, there was a sequence of last-minute problems, so I ran out of time and patience, and chose not to spend more of my weekend packaging another release.

Bug fixes that apply to v2.0 are applied in that branch and then merged to alpha. I often find such bugs while I am working on the alpha branch, so activity in v2.0 does not in any way indicate a lack of work on v2.1. I prefer to push out bug fixes in v2.0 first (even if they've been merged into alpha) so that the changelog will make sense, and all fixes are documented without duplication. This means that when I run out of time, the release that gets delayed is probably going to be the alpha.

"Parity" between v2.1 and v2.0 is not a priority of mine. If it is easier to delay a release than merge bug fixes in parallel with whatever else I'm working on, I'll delay a release.

If you're watching GitHub, you might not see much because I have little reason to push anything manually, as I generally do all the work by myself, and it gets pushed automatically by the release script. The more focused and motivated I am by what I'm doing, the less likely I am to check in regularly.

My immediate plan is to bring struct support and modules to a minimum level of "completeness" that will allow me to feature-freeze v2.1 and move on to other things. Module support is a priority mainly because I hope to use it as a gateway for minor compatibility-breaking changes; i.e. allow the script to opt in for specific modules, while other modules are v2.0-compatible. At the very least, defining a new built-in class without module support would break any scripts that already defined a class by the same name (e.g. Struct). With module support, built-in classes are treated as implicit imports from another module, and anything declared within the current module takes precedence.

This weekend I implemented (subject to change):

• #Module ModuleName starts a new module. As of now, there are no blocks, nesting or any notion of an "outer" module, so no implicit imports except built-ins.
• Each module has its own global variables, and cannot see any global variables of other modules by default.
• Export X, Export Y() {}, Export Class Z: marks an identifier for export, although X might not be initialized.
• Import ModuleName, Import ModuleName as Alias: imports the module, adding only ModuleName or Alias to the current namespace. Importing files is not implemented (i.e. it must be combined with #include; all my testing has been done within one file).
• Export Default X causes X to be imported in place of the module itself when the above import forms are used.
• Import * from ModuleName allows names to be imported as needed, potentially being shadowed by later import statements or declarations within the module.
• Import {ExportedName as Alias, ...} from ModuleName imports specific exported names into the current namespace.
• Each module is auto-executed separately, starting with the last module defined. A module without circular dependencies will execute the modules that it imports before its own body is executed (but all declarations are parsed before any module executes, so functions and classes can be used).

[andymbody]

Thank you sir! For all that you do for this community!

Although... this is so far above my head that the stars have to look up to see it.