It would have been
- CC 15.05-CURRENT
- CC 15.05.0
- CC 15.05.1
-CURRENT just denotes the fact that it is an untagged build from the top of a certain branch.
What you call -STABLE would be proper tags that do not carry any special designations.
We can also consider hiding or not advertising YY.MM-CURRENT builds as those are mainly used for pre-release testing and for providing updated package builds within a release series. It is entirely possible to just expose the actual final versions by symlinking only tagged releases into the public download repository.
Hi @jow. I wonder if we're talking about slightly different things here...
I started this thread in an attempt to come up with commonly agreed upon lingo for distinguishing between:
- a stable release that people can install in their homes for the long term
- evolving software that has bugs fixed and introduced on a daily/weekly basis
We still need to agree on those names so we can use them on the web site, the forum, the download page, etc. to distinguish those two kinds of software. I want the names to give an intuitive understanding of their stability so people can figure out which to choose. (That's why I keep rooting for "Stable" vs. "Development" or something similar.)
You're very right that we also need a unique way to identify each "build" (which I think of as a consistent set of images/packages created from a particular checkout of the source tree). That identifier is definitely the province of the build system, and can be left pretty opaque to most non-developers.
As we move along, I envision we will declare one particular build to be a "stable release" (after approvals, testing, etc.) and that we would preserve that collection of files for history.
Does this make sense? Thanks.
Yeah, and the lingo will be -CURRENT is untested moving target. Anything without -CURRENT is a fixed release.
The idea is that -STABLE after a tagged version number is redundant since a tag is - by definition - stable. And -DEVELOPMENT implies that work is being done in a branch which is not necessarily the case.
Actually I would also prefer the distinction between fixed builds and moving builds as stable implies some rugged, thoroughly tested thing which will receive backports for the next 20 years which might or might not be the case.
Another possible lingo would be to just have releases and snapshots. Anything with a version number (16.12.0, 16.12.1 etc.) is a release, anything else is a snapshot.
Hmm, "CURRENT" does not usually mean "untested moving target" for many users (and also for me). Most people are trained to think that the current or latest release is the best, if you add CURRENT many people will use that.
Since you talk about adding words to the builds, I would replace it with (also note the order, the most recent release is first, then older releases, then the snapshot).
- CC 15.05.2-LATEST-RELEASE
- CC 15.05.1-OLD-RELEASE
- CC 15.05.0-OLD-RELEASE
"old-release" explains what the other entries are, btw. I think snapshots should go in a different place/folder as they are not meant for general public use as you said.
Or simply move old releases in a folder, like
- /older_releases
- /end-of-life_releases
- CC 15.05.2-LATEST-RELEASE
Since you talk about adding words to the builds, I would replace it with (also note the order, the most recent release is first, then older releases, then the snapshot).
- CC 15.05.2-LATEST-RELEASE
- CC 15.05.1-OLD-RELEASE
- CC 15.05.0-OLD-RELEASE
so if someone installs 15.05.2-LATEST-RELEASE, that's what their system will
still show when 15.05.99 is out
you don't change the name after a release is made.
And frankly, if someone can't figure out that if there is a 15.05.2 and a
15.05.1 tht the .1 is an old release and the .2 is newer, I don't think any sort
of naming will help.
the thing about using -current is that all -current or -snapshot builds are by
definition, not stable releases, and they never will be.
David Lang
[quote="dlang, post:27, topic:261, full:true"]so if someone installs 15.05.2-LATEST-RELEASE, that's what their system will still show when 15.05.99 is out [/quote]Ah, I thought that was the name shown on the download page, not the name used everywhere.
The release itself should just have a version, of course.
And add SNAPSHOT if it is a snapshot rebuilt regularly.
[quote]the thing about using -current is that all -current or -snapshot builds are by
definition, not stable releases, and they never will be.
[/quote]Ok for "snapshot", NOT ok for "current".
People use the highest version number that is displayed on the download page and I think that CURRENT will just not be linked there.
Well, if you aren't linking it in the same folder with the releases you probably don't need to call it CURRENT either.
Anyway, that's ok for me, as long as CURRENT isn't in places where it can be read wrong, as I said.
Well, I just renamed it to -SNAPSHOT now to get on with the process.
@jow, your suggestions make a lot of sense from developers standpoint, but they're still confusing to a lot of people removed from development process.
Using both CURRENT and SNAPSHOT is confusing. In [quote="jow, post:21, topic:261"]
- CC 15.05-CURRENT
- CC 15.05.0
- CC 15.05.1
[/quote]
A lot of people unfamiliar with this thread would consider -CURRENT the newest release and the other two obsolete versions. The -CURRENT doesn't convey what it really is -- cutting edge, possibly unstable, it also makes the actual releases look like obsolete versions.
Please settle on RELEASE and DEV(ELOPMENT) tags.
I'm glad that there's a discussion on versioning. YY.MM.R looks to be in-sync with the old OpenWrt naming scheme, so I would totally support that, even if there are other/better versioning schemes for the new projects, unburdened by any legacy issues. Gargoyle went with semantic versioning and now it's impossible to tell which of their releases are based on which OpenWrt version just from the name/number.
Have there been talks about syncing releases with OpenWrt? I'd hate to see OpenWrt and LEDE being on different YY.MM releases or even worse, OpenWrt intentionally delaying their release by one month to appear as a newer release and then LEDE trying to one-up OpenWrt by cutting the time to the new release (or vice-a-versa).
I settled on -SNAPSHOT now, there will be no -CURRENT so we can stop discussing it.
Also keep in mind that untagged builds of release branches that happen to be YY.MM-SNAPSHOT are not meant to be published or user-facing builds. They'll likely be available via rsync but not appear on a fancy download page.
There will be
- 16.12-SNAPSHOT (likely never visible to users on the download page)
- 16.12.0 - first release
- 16.12.1 - second release
- ...
Personally I have no interest in syncing releases with OpenWrt, I don't see how this would benefit anyone.
Personally I have no interest in syncing releases with OpenWrt, I don't see how this would benefit anyone.
agreed, I see lots of downsides and no upside.
David Lang
I totally agree with the notion that version numbers with no suffix (e.g., 16.12.0, 16.12.1, etc) be referred to with the generic/informal term release. Common usage then flows nicely letting people speak of the "latest release" or "16.12.0 release".
I am less in love with the term "snapshot" (see my comment in #4 above for more explanation.) But I could live with it (because of the strong precedent in the OpenWrt world) and if the LEDE team agrees that it's the best term. Thanks.
If you want to enforce rules just because you're making them and not because people agree with the rules created, LEDE isn't going to fare much better than OpenWrt.
The notion that development builds are not going to be visible is not very likely to succeed. If the device support is added (or being worked on) after the last release, do you not want "users" to be able to download and install the "snapshots"? Unless there are monthly releases, the dev images need to be available for download.
If you insist of calling dev builds "snapshots", then at least add the dot-release number in front of it, like 16.12.2-SNAPSHOT, and not just 16.12-SNAPSHOT, as otherwise it's impossible to tell which is newer, 16.12.1 or 16.12-SNAPSHOT.
[quote="dlang, post:35, topic:261"]
agreed, I see lots of downsides and no upside.[/quote]
All generalizations are false.
The notion that development builds are not going to be visible is not very likely to succeed. If the device support is added (or being worked on) after the last release, do you not want "users" to be able to download and install the "snapshots"? Unless there are monthly releases, the dev images need to be available for download.
If you insist of calling dev builds "snapshots", then at least add the dot-release number in front of it, like 16.12.2-SNAPSHOT, and not just 16.12-SNAPSHOT, as otherwise it's impossible to tell which is newer, 16.12.1 or 16.12-SNAPSHOT.
Assigning a number before a snapshot doesn't help much. A git commit number is
about as good as you can get.
Look at what OpenWRT does today, they have their releases (AA, BB, CC, DD, etc)
and they have trunk
you go different places to get each one.
trunk doesn't have any versions (other than a commit id, which can change many
times per day)
That's what we're talking about here. I doesn't matter if you call it trunk,
snapshot, current, master, tip, git, or some other name (and there are projects
out there that use all these names and more)
David Lang
It does help a great deal to get a definitive answer which one is newer just by looking at version numbers. I thought it was evident from what I posted, but maybe it wasn't so I'll elaborate.
Is 16.12-SNAPSHOT newer than 16.12.1? Or has development moved to 17.05-SNAPSHOT and the 16.12-SNAPSHOT is older and was worked on before 16.12.1 release?
See how you don't have this dilemma with 16.12.2-SNAPSHOT and 16.12.1?
It does help a great deal to get a definitive answer which one is newer just by looking at version numbers. I thought it was evident from what I posted, but maybe it wasn't so I'll elaborate.
Is 16.12-SNAPSHOT newer than 16.12.1? Or has development moved to 17.05-SNAPSHOT and the 16.12-SNAPSHOT is older and was worked on before 16.12.1 release?
See how you don't have this dilemma with 16.12.2-SNAPSHOT and 16.12.1?
There never is a 16.12.2-snapshot, snapshots don't have versions.
comparing snapshot to 16.12.1 is comparing apples to oranges.
development is
a-b-c-d-e-f
16.12.0-16.12.1
snapshot is not on the same linear progression as any release.
all snapshots prior to the .0 release being created are before the release.
all snapshots after the .0 release have stuff in them that's not in the release,
but releases after .0 may have things that are different than what's in the
snapshot.
.1, .2, etc releases are not subsets of any snapshots and snapshots after the .0
is made are not subsets of any release.
David Lang