![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Initially (this part is an after-the-fact description):
If Oot ever becomes a real language with a real community, then perhaps we'll switch to a PEP process for finished proposals, augmented with an ideas wiki. Most likely however the breaking/major versions will accept ideas not only through a PEP process, but also through random ideas of the style above.
3 justifications for language or compiler changes: (a) makes the compiler code shorter (b) makes the compiler run faster (c) on its own merits
---
versioning:
We use semantic versioning.
The standard for what is a breaking/backwards-incompatible change requiring a new major version is moderate. We feel free to change unintended behaviors and to correct security flaws. In general, the standard is be somewhat similar to Python; grep for "(Changed by " in https://docs.python.org/dev/what for examples of the sorts of things that Python changes in minor releases.
At any one time, development is going on in two places:
The development of new minor versions in the current major version series, and of the next major version, both use versioning of the form x.0.0-a.b.c.
Here is how the -a.b.c part works ("-a.b.c" is called a "prerelease version" by semver). The 'b' part is incremented to indicate significant changes. The 'c' part is incremented to indicate other changes. The 'a' part is incremented to indicate subjective progress towards a stable new major version.
When it is time for the new version to be released, the 'a' part changes from a number to 'alpha' (after this happens for the new major version, no more minor releases are created for the old major version, and development begins on the NEXT next major version). After 'alpha' comes 'beta' and then 'rc1' then 'rc2' etc (release candidate).
For major version 0, the minor version and patch version are used like 'a' above, to subjectively indicate progress towards a 1.0.
The last minor version of the previous major version of the language receives security fixes, bug fixes, and possibly other small changes such as deprecations and helpers that could help incrementally convert code towards the next major version. The last minor version of the second-previous major version of the language receives security fixes.
(some motivations for the above. Having a 'a' part of the prerelease version to indicate progress towards stability: i feel that Rust is being incautious in their designating an approximate time for a 1.0 before all design issues are worked out, instead i think a project should create what they think is a 1.0, but not call it that yet, and then see what happens for a few months; this is a 'design release candidate', where the design might still change, not a "release candidate" where you are just working out implementation bugs; i envision this being done by bumping the 'a' part of the version for each 'design release candidate'. Cutting off starting new minor versions once a new major version is announced; don't want a Python 2/3 situation; Python already cuts off like that and they still got stuck in this because imo they are being too nice to holdouts)
---
a key principal: at all times, any piece of code that is distributed by Oot is 'owned' by one person (although in some cases, a process must be followed in order for the 'owner' to make changes; which may include getting approval from a higher-level-owner, or via a PEP, or from a committee)
principal: for the most part, we don't believe in 'designed by committee', in the sense that a committee comes to consensus on a design. Instead, we believe in independent designers collaborating in a hierarchical (but forkable) fashion
principal: feel free to fork the language but don't call it "oot"
principal: one canonical implementation. AND a language standard. Where they disagree, this is a bug, but it is not defined which one is wrong and which one is right. Each version of the standard corresponds to (at least) one specific version of the canonical implementation.
principal: when one canonical implementation is untenable, try to adopt the alternative implementations into the oot distribution/project, where they will be released and versioned together. Where alternate Oot versions exhibit different semantic behavior, this is a bug (except where legitimized by the profiles; if there is a good reason for the behavior difference, this difference should be added to a profile, or a new profile should be created).
principal: the primary goal of each of the implementation and the standard (after the inherent goal of correctly and comprehensively describing the language) is readability
principal: a small implementation is more readable. Performance enhancements are fine but whenever possible they should be structured as optional modules, so that a person running the canonical implementation could remove them and still have it work. So, the canonical implementation will have a 'core' that is much smaller than the full implementation (this 'core' is the 'reference implementation').
principal: the motivation for the PEP stuff is to give the community visibility, to document the thinking behind decisions, and to solicit input, but not to give the community formal control.
also, often an owner is required to present their changes for comment, even when they aren't obliged to follow what the commenters say in every case. E.g. owners should always get their changes reviewed by one other person when at all possible, but this doesn't mean that two people must come to consensus for every change (the owner may overrule the reviewer)
principal: for releases, we care more about the absence of bugs than about featurse
principal: within one major version of the language, we care about stability. We don't care about much stability across major versions. In some cases, it may as well be a whole different language. (why don't we rename the language then? b/c of this:
Misc notes: "its successors Modula and Oberon are much more mature and refined designs than Pascal. They form a family, and each descendant profited from experiences with its ancestors....Why, then, did Pascal capture all the attention, and Modula and Oberon got so little? Again I quote Franz: "This was, of course, partially of Wirth's own making". He continues: "He refrained from ... names such as Pascal-2, Pascal+, Pascal 2000, but instead opted for Modula and Oberon". Again Franz is right. To my defense I can plead that Pascal-2 and Pascal+ had already been taken by others for their own extensions of Pascal, and that I felt that these names would have been misleading for languages that were, although similar, syntactically distinct from Pascal. I emphasized progress rather than continuity, evidently a poor marketing strategy. ... But of course the naming is by far not the whole story. For one thing, we were not sufficiently active -- today we would say aggressive -- in making our developments widely known." -- http://www.swissdelphicenter.ch/en/niklauswirth.php
)
---
we need some sort of a deprecation process so that ppl know how much they can rely on stuff
note that since we are using SdVer? not SemVer?, breaking changes happen at minor revisions, not major.
security updates and other 'critical bugs' could necessitate any sort of breaking change at any time, so the rest of this discussion has that exception implied.
also note that none of this applies before major version 1.0.
Consider backwards compatibility edge cases:
---
when would oot be bug enough to warrent a 1.0? a large number of ppl would have to strongly request it. how large? compare reddit members, github stars, redmonk etc for ither small langs nim has about 300 contributors right now, 300 github watches, and 10k github stars and 1k github forks. mb if Oot had 1000 contributors who signed a petition to stabilize. counting only contributors petitions rather than anyone also ensures manpower for maint. note: want this number to be small enouf to not allow a successful fork by a subcommunity that wants stability
---
i think we should have up to 2 supported implementations on each platform:
consider https://ziglang.org/#Tier-System , but i don't think its right for us. Probably more on target would be a system about how 'supported' they are; does the core project distribute and support them, are they officially recommended, or are they just indie?
---
i'm thinking Apache 2.0 license.
i really like Blue Oak tho: https://blueoakcouncil.org/2019/03/06/model.html
but if even the authors cant be bothered to submit it to OSI, then i doubt it's going anywhere.
mb dual:
Apache 2.0, or Blue Oak 1.0.0
i dunno. probably just Apache 2.0.
---
