This Editor wants to provide a free, easy and comfortable writing experience.
Therefore we chose
, our binding to
, to realize it.
Our goal is to make this software crossplatform, nonintrusive and interoperable.
To ensure a free reuse of the sources the Editor is released under
From the beginning I wanted clear and understandable version numbers. But this
is not a question of digits, but of release cycles, because counting them is a
concept that is understood very well. These cycles have to fit to our developer
team and our goals to produce something well polished and rock solid. On the other
side I also want to communicate any changes as fast as sanely possibly and have
a scheme that can display progress realistically. But you can't have all at once,
or at least you have to study the upcoming problems carefully to make a good choice.
Free software development is often driven by a longterm vision or some (often)
technical goal. The releases toward this goal are counted by the second digit
after the first point. Only if a new vision is realized, the software has some
new foundation or is largely rewritten it gets the number 2.0. On the other hand
commercial development is mostly driven by the impression it tries to give its
audience. So each new version is marketed as the shiny new thing with a new first
digit or even a new name or at least some additional letters to identify this
special release. Large software packages know sometimes incremental steps, or
minor releases are presented as free bonus. But by in large do companies promote
their products as large achievements and big releases without a dot after a number.
I don't have a clear and detailed vision but I know in general what I wish and
whats missing in most other editors. To me marks 1.0 a level of satisfaction and
feature completeness I dream of. Because the way toward it is not the shortest,
every sub release with one dot will be stable, polished and in itself complete.
Maybe this scares some people away, that think 0.n versions are just a beta or
not that evolved. But I can't think of any good intermediate goal. Maybe when
the 5 core extension I need are ready to use (library, command line, debugger,
source outline, file/project/version control manager) there will be a 1.0.
Another decision one have to make is between releasing when a feature is ready
or releasing on a time schedule. The ladder became more popular among projects
like Linux and parrot and I agree that having regular releases is a strong signal
that this project is alive and that you can depend somewhat on the work done here.
It also helps to schedule and organize things that relate to that project.
On the other hand I want to have for any testing release at least one bigger
feature that teases people to use those versions. If that feature gets stable,
this release will be shipped. And because after several test versions comes the
stable this will always bring several new things. But if, for whatever reason,
no larger improvements seen daylight I want to have a stable release every year
or half, a testing release every 2 or 3 month.
That is another big one and has do with the question to release on time or when
every problem is shaken out. While a testing release may have some minor problems,
a stable never should have known issues. But even if you have a decent test suite,
many bugs will be found when a version is out. Thats why we make testing versions,
to catch as much as possible bugs before the audience can see them. But because
the main audience are much people, many bugs will be found when the stable is out.
Our "no known issues" demands to fix that immediately. But under which number?
The regular development will be long gone to further counting (e.g. 0.4.0.11).
Backported bugfixes are no regular development and should be also counted in a
different way. The end user also should have his version with a short and sweat
number like 0.4. So we add a patch level ("pl" in short) that will only appear
on the download page and the info box. The user can this compare if an issue is
fixed in his version of 0.4 but most of the time just use "the" 0.4 version.
In summary: I am very concerned with stability but version number have to count
the development. There will be no release candidates or beta versions just test
releases, that might have issues but will not crash at the best of our knowledge.
In some info boxes can also be found revision numbers, but i don't prefer them.
Together with the version they are too long and it doesn't says much at all.
With Perl we also don't compile and and don't need the info, what is bound with
what. SVN counts revisions for us. If we make a release, we mark it in the RCS,
not the other way around. But indeed the steps between test releases are large.
Enough to justify a fourth cycle that counts important commits. Testing releases
will be available like stable, but for the dev team, friends and hardcore tester
we release nightly versions on a separate site. This will be helpful to have
even more testing and better coordination inside the dev team.
I'm overall happy with the described model, because it does focus on what is
important to me and enables quick development (no stable branch). It has 4 level
of release cycles. Each for a distinct different purpose, so that the length of
a version number can tell for what audience it is made and what to expect from
it, without having much additional marks and letters.
© 2012 Kephra Project