![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Initially (this part is an after-the-fact description):
If Jasper 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
maybe use semantic versioning.
At any one time, development is going on in two ways; in previous major version, and in the experimental/development version (versioned via pre-release identifiers). At some point, open-ended development stops in the pre-release version, and it transitions into testing (alpha, beta, rc, etc) and then into release; at this point, (a) new releases stop being developed on the old major version (although whatever new release was currently in development is finished, and maybe the next one, if development had already started on it), (b) a new experimental/development version for the next major release is opened.
The experimental/development versions' prerelease numbers are in two parts, a 'minor revision' number and a 'patch number'. The minor revisions are incremented to indicate significant new ('public API'-changing, e.g. language changes, not just toolchain improvements) functionality, and the patches are incremented for everything else. Note the presence of 'significant' there; in the experimental/development versions, generally the minor version number should only be incremented when at least one of the changes since the previous minor version has been discussed in a PEP (and, any change that has been discussed in a PEP warrents a minor version bump in the prerelease).
So e.g. you'd have Jasper 2.2; and simultaneously Jasper 3.0.0-22.3.
In the released series, you'd have the same thing going on with the next minor release.
So e.g. you'd have Jasper 2.2; and simultaneously Jasper 2.3.0-11.2; and simultaneously Jasper 3.0.0-22.3.
At some point Jasper 3.0.0 would start moving towards a release, at which point an 'alpha.' prefix would be introduced, a minor and patch pre-release would still be there (because in alpha and beta we still would probably have occassion to change things, not just fix bugs, although we'd try not to, trying not to harder in beta than in alpha), then it would go thru e.g. Jasper 3.0.0-alpha.0.0, Jasper 3.0.0-alpha.2.11, Jasper 3.0.0-beta.0.0, Jasper 3.0.0-beta.1.11, Jasper 3.0.0-rc.0, Jasper 3.0.0-rc.3, and finally Jasper 3.0.0. When Jasper 3.0.0-alpha.0.0 was created, creation of new minor development versions of Jasper 2.x would not occur anymore (e.g. Jasper 2.3.0-11.2 would still be developed into Jasper 2.3.0, and that would still be patched, but no Jasper 2.4.0-* would be created); that activity would move to Jasper 3.1.0-*.
?: to which of these versions is a PEP-like process (sorta) strictly applied? i'm guessing, only the the minor releases after the major release. A PEP-like process is sloppily applied to the next major release? Perhaps we should also have a 'sandbox' version without any PEP process being applied (more of a pure BD (benevolent dictator/dictatorial) process)? Or perhaps instead add another grouping to the pre-release versions that can only be incremented when everything included has been documented in a PEP-like thing?
A: the solution i like best is to have a 'bayle's sandbox' branch off of the experimental version; because the latest 'bayle's sandbox' will always include the changes from the latest experimental version. Then require at least a short PEP-like thing before inclusion of new stuff from bayle's sandbox into the actual experimental version. Recall that one of the ideas of a PEP is to alert the wider community that a change is being considered, so that people who have criticism can state it. Note also that stuff can be put in in one experimental pre-release version and then taken in in a later experimental pre-release version; so it's not crucial for the PEP discussion to terminate before the decision is made to put it in there. Instead, there is a lower standard: something goes from the sandbox into the experimental prereleases when the BD thinks the change is sufficiently likely to remain so as to make it worthwhile for contributors to experimental to merge with it now.
---
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.
---
a key principal: at all times, any piece of code that is distributed by Jasper 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 "jasper"
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 jasper distribution/project, where they will be released and versioned together. Where alternate Jasper 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
)
---
