![[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
)
---
