Last night a new pre-test Emacs version was released (OS X link). The pre-test version is 24.3.90 and the current nightly version number is 24.4.50.1.
This made me wonder, what version number are the subsequent releases of pre-test versions supposed to converge to, and how is this version number determined? For example would the pre-test end on 24.4 and then there will be a new stable 24.4 version? or will they converge to some other number of the 23.4.* series since the nightlies are already moving beyond 24.4?
Also, what is the difference between the pre-test, release-candidate and preview versions?
Finally, when I go on Wikipedia, Wikipedia highlights a current preview version (24.2-rc2) even though we have already have a stable version (24.3) that is more recent than the preview version. Why highlight a preview version after a stable version has already been released?
Previews, pre-tests and release candidates
“preview” is Wikipedia “slang”, and seems to refer to Release Candidates. You'll need to ask the authors of the corresponding article, why the preview versions are listed. I presume that whoever edited the article to announce the Emacs releases simply forgot to update the the “preview” section as well.
Pre-tests are pre-release versions intended for public testing, distributed as tarball from the GNU FTP servers. While approaching a release, pre-tests are frequently released to get testing and feedback from the community.
Release candidates are simply the last pre-tests immediately before the final release. Roughly speaking, a pre-test becomes a release candidate if the maintainers feel that Emacs is now stable enough for a public release.
Version numbering
The current Emacs trunk always has the version number X.Y.50, where X.Y is the major and minor version of the last release. On the road to the first pre-test, the trunk is frozen for features, and only bug fixes are committed. With the first pre-test, the trunk is moved to a special branch, and it's version number is increased, to the version number of the next release.
The subsequent release process happens on the special branch. The first pre-test gets the version X.Y.90, where X.Y is again the major and minor version of the last release.
The final release then gets the version number X.(Y+1), and is tagged.
Hence, before the first pre-test of Emacs 24.4, the nightly builds had the version number 24.3.50. With the first pre-test 24.3.90, the nightly builds became what will be Emacs 24.5 in some far future and consequently now have the version number 24.4.50.
The pre-test versions will increase as subsequent pre-tests are released (e.g. 24.3.90, 24.3.91, etc.) and ultimately converge to 24.4 which is the final release.
Disclaimer
I'm no Emacs developer, so the above may be inaccurate.
Related
I've recently started working on my own project, I've added to project to github and I'm learning the reigns with using a source repository.
I have some questions as much of this is new to me:
Version numbers. How do I decide what qualifies as a new version? I work on the project daily
and make many small changes. do I write down a changelog? Should I add this with every version? What's Common agreed Practice?
What are the requirements and criteria for an Alpha buuild?
What are the requirements and criteria for a Beta build?
Since you are using git, use the commit history as your change log. Just make sure you are writing short but descriptive messages.
Most of the software I write is uses Major.Minor.Revision for my visioning.
Major - Software version. This will only increment if I make a huge
change to the code base or rewrite it all.
Minor - Release. This
changes when I merge changes from the development branch to the
master.
Revision - Patch number. this will constantly be changing,
this is how many times I have pushed to the branch since incrementing
the Minor.
An example would be:
1.0.0-dev -> 1.0.1-dev -> 1.0.2-dev -> 1.1.0-rc & 1.1.0-dev
Should I have to make a hot fix I would release 1.1.1-rc and 1.1.1-dev.
As for the requirements for alpha/aeta, you can set your own criteria but normally alpha is usually where you add features to your code and fix the major issues, and beta is where you fine tune your code.
Some good references that go into more detail than I have are:
http://en.wikipedia.org/wiki/Software_release_life_cycle
http://en.wikipedia.org/wiki/Software_versioning
This is my open source code I wrote.
https://github.com/simkimsia/UtilityBehaviors/blob/master/README.mdown
I have a No Stable Release from packagist.org
How do I go about having a Stable Release sticker from packagist?
You have to tag your code with a version number.
git tag -a 0.0.0
That will declare the first stable version. If you worry about an all-zero version number, you can start with something like 0.0.1 if you want. Try to stick to semantic versioning if you can: http://semver.org. After that you should push the to the public repository, like git push --tags.
Note that you can use the whole array of stability labels in your tags. There is everything from alpha, beta, release candidate recognized by Composer. See http://getcomposer.org/doc/04-schema.md#version for info on how to create a version number.
Packagist will then scan your repository and process that tag, which is a "stable" release, and mark your package accordingly (even with the 0.0.0 version number - 0.x software is not different from 24.x software in terms of Composer/Packagist).
Edit 2016-07-14
Note that version numbers in semantic versioning are handled different if they start with 0.x.y. This does not affect tagging and releasing in any way, but it affects the way users can select and update your released software. Any software in the 0.x range is considered an incompatible if you release the next minor update 0.x+1. The Composer tilde operator ~ will not be disturbed by this: ~0.x (with any integer as x) will update to the next minor version. The caret operator will behave different: ^0.x or ^0.x.y will stay in the 0.x range and not go to any 0.x+1.y release.
The best way to counter this would be to start with 1.x versions, and use stability flags to indicate possible changes. You can use 1.0.0-alpha1 as your first release instead of 0.0.1, later releases may be 1.0.0-alpha2 for another "unstable" (read: API not finished/stable) release, then go to 1.0.0-beta1 for API-stable, but internally unfinished releases, then 1.0.0-rc1 for possibly API-stable, finished releases during final bugfixing phase, and then 1.0.0 for the final release. More bugfixes will be 1.0.1 and up, new features will be 1.1.0, incompatible API changes will be 2.0.0. Note that the first users may use ^1.0.0#beta as their version requirement, and as development progresses, will always get the newest update without the need to change their requirement (unless you break your API and force updates that way). This will never work if you go the 0.x route and then release the final product as 1.0.0, because you have at least the obvious incompatible update jump to 1.0.
It's hard to decide without future knowledge whether a package proves to be useful and creates a happy user base (who will benefit from a 1.0.0#alpha release tag), or if it is only an interesting experiment that nobody is using in production (a.k.a. 0.x).
My personal preference for internal private packages is to make them 1.0 from the start. I have to deal with several packages that started at 0.0.1 and are a bit nasty when updating because they are mature, but cannot go to 1.0 because of that incompatible version step, which would involve a lot of work in secondary packages.
I am looking to start a project with distributed source control and am evaluating the different options. Looking at Bazaar, I stumbled over several articles (e.g. this) that development has slowed down significantly.
What is the status of the project bazaar? Are bugs getting fixed?
I will try to answer first with facts.
1/ According to the Active (published) Bazaar branches of Bazaar, we can see that there is 8 active development branches (changed since beginning of 2013)
2/ According to Bazaar 2.6b3 milestone, 3 bugs out of 12 are fixed for the next 2.6b3 release. This version started 6 month ago (August 2012).
3/ According to Bazaar v2.5 series, v2.5 series had a beta/minor release every month.
4/ According to Bazaar v2.6 series, v2.6 series has a beta/minor release every 4 months (well, there are not so many releases to give trends here).
5/ Bazaar is still used on prestigious/ambitious/large projects : Ubuntu, Debian, MySql , Launchpad ... projects that are active in the Bazaar community.
So the first observation is that releases are less frequent, clearly.
One may think it's bad trends, but one can consider that the application is now mature enough and that new road map (with new features) needs to be forecast.
To finish, here is an extract of a IRC chat I had with bzr team. This may point out the issue with intermediate release.
trident_job: Hi there. I've seen that latest bzr version is v2.6.2
and is 1 year ago (nearly).
trident_job: next version v2.6.3 still
have 3 bugs to fix ... do you think the project is stall ?
mmm: we lack anyone who's job it is to do the release these days
mmm: you're right that there's stuff on trunk that could have done with being
released a good while ago
trident_job: mmm: yeah, that's not good
advertisement for an open source project to have 1 year release cycle
mmm: well poked... so, probably an rt unfortunately
UPDATE 2013.09.20 : Bazaar retrospective from a dev.
Read especially the last two chapters :
Bazaar on the slow track
Conclusion
In my current project I have to decide which technique to use when branching. I have two options (we'll assume that we already have decided to develop in the trunk):
Version branches
Make a branch whenever a new version is put on the test machines and tag it like "release0.1". Bugs are fixed in this branch (and then merged to the trunk of course) and when this release finally goes live it's tagged "release0.1.1". This leads to having a branch for every major version and a tag for every minor version. If a bug has to be fixed in the live-version, it's fixed in it's appropriate branch and then merged down to the trunk.
Version promotion
Have only three branches "trunk" (for development), "test" and "live". When a version is put on the test machines, the trunk is merged (promoted) into the "test" branch, bugs are fixed in that branch and when the version is released, the "test" branch is merged into the "live" branch. If we find a bug in the "live" branch, it's fixed there and then merged down to the trunk.
What are the pros and cons of these two philosophies? What are your own experiences? Are there any other - possibly better - methods available?
It depends on your maintenance policy.
If you choose to maintain more than the latest release (XP in parallel to Vista for instance), version branches is a better choice.
From my experience version promotion has much smaller overhead on merging changes from different branches and trying to remember what was fixed on which branch, etc. so whenever possible I prefer to work this way. Unfortunately, if you use version promotion it is often not possible to do small quick fixes on the released version (because there are big chunks of code checked in to the "test" branch) -> so we and up having version branches.
To sum up I think (for me at least) usually the best way is to do something in-between the two - do all development on trunk (main branch), tag all builds/releases, and create a version branch only if needed (e.g. there is a critical bug in production, and there are changes in trunk that can't be released).
In my opinion, the two are note exclusive.
The version branches mecanism is needed if you have to maintain different RELEASED versions. But I think it is a best-practice to always prepare a branching point (depending on your gestion version system) after releasing a version.
The "promotion" mecanism is needed if you have to release test version. This is usefull if you have, for example, a validation team distinct to development team and/or large team where development goes fast. In these cases, you need a specific branch to stabilize the next "stable" release while trunk stay "unstable".
If you have a version 1.0 of a product, or say 1.1 or even a patch, do you create a tag/label or a branch?
Eric Sink wrote a great series of articles about the ins and outs of version control. I'd suggest using those as a starting point.
Depends on the version control system. I'd branch for incompatible (major version number) changes, and tag for compatible (minor version number) changes. That leads to a whole discussion about what's compatible and what isn't, though...
Or, just use Subversion, where you'd normally use "svn copy" for either.
I usually don't branch but only label the releases. This way, I can branch later when the need arises. Since branches are so expensive in CVS, try to avoid them until you really need them. For all other VCS tools, branching is so cheap that you can do it as you need it, so no need for premature actions, either.
It depends a bit on the tool (version control system) you use, if it has sane branching and tagging.
In Git I would use tags such as v1.0, v1.1 to point to exact version (tags do not change), so if somebody would tell you that there is a bug in version 1.0, you would know exactly what it contains. If there would be a need for long-term maintenance, I would use branches such as maint-1.0 and maint-1.1 to gather maintenance bugfixes for past version, and from time to time tag new minor release such as v1.0.1, or v1.1.5.
HTH