What should we call the current builds?

Talk about Documentation
1

Both @hnyman and @bobafetthotmail mentioned (in these postings: LEDE Table of Packages: Good or bad? and LEDE Table of Packages: Good or bad?) that "trunk" isn't a good name for the current set of builds.

They also suggest using the name "nightly" or "snapshot" to talk about these current builds.

I prefer "nightly" because it says what people would be getting: the result of a rapidly changing process that's becoming ever-better.

Once we get a release plan in place, people will be able to choose between a "nightly" build, with the latest stuff, or a "stable" version that has considerable testing.

Thoughts?

2

We already use "snapshots" name in the download path:
https://downloads.lede-project.org/snapshots/targets/

Also "trunk" makes no sense at all, we don't use svn anymore. Is this even mentioned anywhere? I don't think it should.

I don't see much gain from renaming "snapshots" to "daily" or "nightly".

3

[quote="rmilecki, post:2, topic:261, full:true"]Also "trunk" makes no sense at all, we don't use svn anymore. Is this even mentioned anywhere? I don't think it should.[/quote]Mostly on documentation coming from OpenWRT wiki where "trunk" is still the name for OpenWRT snapshots, I will replace it with "snapshot".

[quote]I don't see much gain from renaming "snapshots" to "daily" or "nightly".[/quote]"snapshots" name by itself does not describe that these are from development branch (master), at least imho.

I know it's bike-shedding.

4

The reason I am attracted to "daily" or "nightly" is that it immediately conveys the "timeliness" of the image. You intuitively grok that it's today's version, and there will likely be a new one tomorrow.

For me, "snapshot" conveys an important saved state. I have snapshots of my VMs, snapshots of a website at a particular time, etc. Those snapshots preserve something that I might, someday, wish to return to.

So I'd lobby for the word "daily" or "nightly", and then lobby that we apply it everywhere - in the wiki, the forum, and the name of the directory on the download server.

5

Except that the builds are not really nightly or daily, more often than not, there're multiple revisions happening on the same day of active development and there are days when no new revisions happen.

There's also no connection between a particular day and the revision number. Like if I say I'm on Cyanogenmod from October 18th, it makes it cm-13.0-20161018-NIGHTLY-*.zip. If I say I'm on a "nightly" build of LEDE from a particular date, who the hell knows which revision is it.

I would suggest you guys figure out the stable naming in advance (and I would suggest 1st LEDE release to be at least abbreviated DD, if not just be Designated Driver to sync with OpenWrt release names) and then call the images either RELEASE-stable or RELEASE-development, so DD-stable or DD-dev to shorten it.

I'm not in the know about the latest developments on how OpenWrt and LEDE will coexist, but it would be a great help if LEDE continued where OpenWrt left it (DD) or if both projects are to continue forward that the release names be synchronized, as to avoid confusion which release is newer. That of course would require coordination between projects to name releases based on measurable criteria, like the kernel version or something and not just "our next release".

I strongly believe CM has messed up on that one, there's no reason (besides legacy issues now) that CM14 is called CM14 rather than CM7.1. Their numbering is arbitrary, doesn't even coincide with the SDK version.

To summarize, call them stable and development (dev). Both words perfectly reflect what the builds are without creating any confusion.

6

Indeed, HEAD or -CURRENT seems like a sane choice? That's what BSDs have been using for years and it works fine? :slight_smile:

7

[Slightly OT - thanks for this open discussion. I believe that one of the most important tasks we founders can achieve is in selecting names for things. A well chosen name helps people understand stuff immediately; a badly-chosen name means there's always a bit of confusion, a moment of hesitation, especially for newcomers. Let's get this right.]

Some thoughts on the discussion so far:

  • I like making the distinction between "stable" vs "development" builds.
  • Given that there are potentially 0, 1, or many builds in a particular day, I am happy to give up the notion of calling them "daily" or "nightly".
  • "head" vs. "current" vs. "trunk" vs. "master" vs. ... - these are tied to version control, and don't really convey valuable info for newcomers.
  • I don't have any idea if/whether LEDE will ever re-integrate with OpenWrt . We should come up with our own consistent naming scheme which can be aligned/harmonized with OpenWrt's status if need be.

To put my thumb on the scale, I (currently) like the names "stable" vs "development" builds.

8

[quote="richb-hanover, post:7, topic:261, full:true"]- "head" vs. "current" vs. "trunk" vs. "master" vs. ... - these are tied to version control, and don't really convey valuable info for newcomers. [/quote]Yes, this is the main point here, using a name that is obvious for non-developers. Really, developers don't need names (nor releases). :relaxed:

I also think that going with "LEDE stable (v1 v2 whatever)" and "LEDE development" as names is good enough for this.

9

I prefer semantic versioning. Example and a easy explanation https://drupalize.me/videos/semantic-versioning

10

I like stable + dev(elopment) for this reason.

11

From the video: "It's just a clear message to people who are using this software"

Looking at OpenWrt from a userperspective:
"Can I easily update from 14.07 to 15.05.1, without breaking stuff, without having to reconfigure everything?"
The current date-based naming doesn't answer that question, while semantic versioning could, IMHO.

Can I easily update from LEDE 1.1.3 to 1.2.0? -> Yes
Can I easily update from LEDE 1.1.3 to 2.2.0? -> No, there might be more work to do than just clicking "Update".

Stable / Dev could be expressed with even/odd numbers:
1.2.0 -> even minor number = stable
1.3.2 -> odd minor number = dev

I like this better than date-based naming.

I have no feeling for how often a major update would occur for an OS like LEDE. Anyone can answer this question?

12

I think versioning scheme remains opaque to anyone that isn't involved with the project already.

Dates are good enough, for answering questions there is documentation or FAQs that are far more friendly.

13

I feel that the realistically the release cycle will be 6 months or longer.

It is good to remember that LEDE is not a singular software, but in addition of the main source it is a compilation of ~1000 packages for ~50 platforms. Trying to e.g. have monthly releases is not realistic, if the expectation is that the packages would remain downloadable for a few years / permanently.

From that perspective I like the date-based versioning. A good reference point is Ubuntu, which has a 6-month release cycle and is similarly a compilation of various packages.

14

I disagree about using semantic versioning as defined by @steinmb. LEDE is a collection of different packages (which might use their own semver scheme) flying in loose formation. LEDE needs an overall name for each of its stable releases, which define a specific set of packages.

I'm not sure what we should use, though. There are lots of possibilities:

  • I am attracted to the notion of date versioning - 17.02 if our first stable release came out in February 2017. Minor versions could be 17.02.1, 17.02.2, 17.02.3, etc.

  • However, the version (e.g. 17.02) should actually match the yy.mm that the software actually ships (or at least enters RC). It was confusing that CC was named 15.05, but actually came out more like 15.09 or 15.10...

  • It's also fun to tie the number to a name for memorability. For example:

Ubuntu has its 16.04 (Xenial Xerus)
OpenWrt has its 15.05 (Chaos Calmer)

  • (Slightly tangentially) I still like the distinction between stable and development, where stable is an officially released version (however we name/number it) and development is whatever is currently being built.
15

Here is one of the reasons I suggested using another scheme then dates.

LEDE-1.x-dev

  • At some point feature freeze. (set by date). No new functions.
  • Bug fixes patches only. API changes should not happen.
  • Roll LEDE-1.x-alpha/beta.
  • Roll a golden and bring out the fizzy drinks.

LEDE-1.0.x
Lets say this lives for a long time. Keep getting fixes and the code mature. Releasing 1.0.1, 1.0.2 and so on.

LEDE-1.1.x
People want to provide new functionality.

  • Completely new functionality is easy. Just add it.
  • Extending existing, a little more challenging then code need to make sure existing config do not break and so on.
  • Project need to make sure upgrading from 1.0.x to 1.1.x works. Test bot driven. What have you.

After many years and the world changes, the team realize that a few of the ways stuff done should be different. I'm talking about major architecture, data storage, API and so on –changes
.
LEDE-2.0.x
New generation is born.

  • Will there be a upgrade path?
  • Should there be one?
  • If so, anyone have time write one, test it?
  • Update documentation.

Questions:
My ting about date based based numbers. How can a user know that a upgrade will not break? If a look at, lets say version 16 and I want to to install 17. How I as a end user know? Yes, someone need to take time and write a doc. page and so on. But we are developers, we hate writing doc. and we should not if we do not have to.

How can the project developers introduce scary new stuff, alter API, generations of libraries and so on and still be sure it will not break for users using a, b, c. Writing code that make sure old versions never break if they upgrade take a lot of time.

The same goes to developers. It would be nice that a package developer could write magic into the package preventing it from getting installed on a generation of LEDE it was not tested/written for. This last bit would probably be controlled by dependency management of the package manager so no sure how much it apply. Here I'm talking about packages/modules/extensions to LEDE core or the UI, and not generic software written for something else and cross-compiled/ported.

That LEDE build on other packages, libraries and so on is nothing special. All larger project do.

I find LEDE an exiting project and looking forward to follow it though out the years and see how and where it goes :slight_smile:

16

[quote="steinmb, post:15, topic:261, full:true"]My ting about date based based numbers. How can a user know that a upgrade will not break?[/quote]Easy, the upgrade path is different. You just install packages to keep LEDE updated while inside a release, you reflash a firmware to upgrade between releases.

LEDE sysupgrade (needed to upgrade between releases) nukes and rewrites the whole system. It backs up/restores only configuration files (although it is advised to not do this without doing some checking config changes between major versions). Packages are NOT backed up in any way and this is clearly stated in the appropriate page https://wiki.lede-project.org/docs/user-guide/firmware-upgrade

[quote]If a look at, lets say version 16 and I want to to install 17. How I as a end user know? Yes, someone need to take time and write a doc. page and so on. But we are developers, we hate writing doc. and we should not if we do not have to.[/quote]1. versioning schemes are opaque to non-developers, most people won't know that upgrading from version 2.3.4 to 2.3.5 is safe by just looking at numbers (also because many projects use random versioning schemes), so we'd still need to write docs and answer people in the forum.

  1. there are wiki maintainers (me, richb-hanover and tmomas)

[quote]How can the project developers introduce scary new stuff, alter API, generations of libraries and so on and still be sure it will not break for users using a, b, c. Writing code that make sure old versions never break if they upgrade take a lot of time.[/quote]Old versions are just frozen versions of the development branch receiving patches only if really needed. Ever seen Linux's development?

[quote]It would be nice that a package developer could write magic into the package preventing it from getting installed on a generation of LEDE it was not tested/written for.[/quote]The feeds the packages come from are going to be different, just as with OpenWRT.

If you look at the repos in github you will see branches for OpenWRT 14 and 15. Developers only push bug fixing there, and the build bots build the packages for a release from that release's branch.

[quote]Here I'm talking about packages/modules/extensions to LEDE core or the UI, and not generic software written for something else and cross-compiled/ported. [/quote]All LEDE and OpenWRT community-maintained package feeds follow the same scheme.
What works in HEAD is assumed to keep working after the release freeze, until someone opens a bug report.

17

@steinmb does a good job of describing a release history along the lines of LEDE-1.0.x-dev -> LEDE-1.0.x -> LEDE-1.1.x -> LED-2.0x -> ...

I think the LEDE development/packaging model is a bit different from what you describe. If I'm not mistaken, here's how it works. (Please, someone, correct me if I'm wrong...)

If you're using version X, all the packages that are available have been built at the same time as the base LEDE system. Therefore, they are always compatible.

If you upgrade to LEDE version X+1, you'll get a different set of packages that were also built contemporaneously, so they'll work together.

Our first stable release will simply be the (static) set of images plus packages built on the release date. The development version will continue to generate new versions+packages as its own consistent set (which might possibly be incompatible with earlier versions.)

And developers are free (in the development branch) to propose/implement any scary stuff as long as they keep it in the development branch. (They'll keep it in their own private repo's while it's in really scary condition, and only commit when they think it's working...)

18

The thing is that you can't ever know that an upgrade won't break.

Remember that the LEDE team does not control all the software, so they can't say
when an API change is allowed and when it isn't. All they can do is say "we
tested these versions of packages together and didn't spot anything in our
testing"

There is one exception to this. Once a stable version snapshot is created so
that you aren't going to be pulling new versions of upstream for anything, the
remaining changes are within the control of the LEDE team, so going from x.y.1
to x.y.2 should always be safe.

But change the values of X or Y and you have lost all guarantes. going from 16.4
to 16.5 is just as ugly as going from 16.1 to 17.1.

The only value in having a 2-part version is so that people can get a rough idea
of the age of the release, which indicates the approximate age of all the
packages in the release. If it wasn't for that, just using sequential numbers
would be perfectly fine. But there is enough value in having the date be part of
the release that a lot of projects make use of it.

David Lang

19

I lean towards the -CURRENT notion as well. My idea is to call "trunk snapshots" CURRENT and release branch snapshots Major.Minor-CURRENT. See also my RFC at http://lists.infradead.org/pipermail/lede-dev/2016-December/004384.html

20

What happens when are many generations of releases? My concern is confusion for newcomers who ask the question, "Which one is the current current version..."

Let me use OpenWrt as an example (since I'm familiar with it...) to see if I understand your suggestion. There would have been:

BB 14.09-CURRENT
CC 15.05-CURRENT
CC 15.05.1-CURRENT
DD-CURRENT

I don't see that the suffix adds any information to the name.

My preference would be to differentiate between development and use "STABLE" for declared final releases, e.g.,

BB 14.09-STABLE
CC 15.05-STABLE
CC 15.05.1-STABLE
DD-CURRENT

Or even leave off the "STABLE" suffix, since the version [ name | number | whatever ] we choose can stand on its own as a marker of a particular point/release in our evolution.

I realize that this has some implications for the build system, and I'm hopeful that it doesn't throw in too much of a monkey wrench...