@jow has released a master plan for how LEDE will be released. It documents the scripts/build system/etc. that's in place to create the first stable build, then create subsequent releases.
The message is out for comments on the LEDE-adm list now, at: http://lists.infradead.org/pipermail/lede-adm/2016-December/000314.html
While a lot of that went totally over my head, one thing I found disconcerting is that the code name is being discussed only in terms of the first release.
I believe it's helpful when code names themselves provide enough information to judge which one is newer (AA<BB<CC<DD or GB<ICS<KK<M<N-- it's evident which one is newer). So I would hope that either code names are not used at all (so it's just LEDE-xx.yy.n) or that the code name logic is thought of ahead of time for the foreseeable future and not just the first release.
Honestly, I don't give a toss about code names. I always found the OpenWrt ones a wee bit silly, and they really don't carry any specific meaning. Also keep in mind that with the proposed release cycle we would see more than one release a year, so they'd burn through half of the alphabet in a few year's time and it becomes pretty meaningless. Better to refer to them by their "version number", which is in itself already more of a "code" than a version indicator.
What bugs me a little bit more is that they are apparantly ditching the LEDE moniker and going back to "OpenWrt". I mean, I get it, it's an established name and all. But then the "Wrt" part calls back to the classic WRT54G* devices that have not been supported in years, made by a manufacturer that recently hasn't exactly covered itself with glory when it comes to everything Open Source. I'm not particularly fond of the name "LEDE", but reverting to "OpenWrt" marks a missed opportunity in my book.
That might be with the remerge in mind.
I found @jow's write-up to be pretty lucid. Really looking forward to a stable release, that will clear one more hurdle for people looking to migrate from Chaos Calmer.
Hold your horses - it's being discussed. I have read the minutes on the mailing list, my understanding is they are still talking about it, nothing has been decided yet.
Personally, I think returning to the OpenWrt monniker isn't all that either. But there are pros and cons to every solution, and like one of the devs pointed out, settling on the name will be one of the hardest discussions.
I've noticed someone mentioning this on the mailinglist, but for completeness sake I would like to mention it here as well: I would love to see the airtime fairness patches that are currently in the staging tree to be included in the first release. I believe this to be an important feature with a large impact for the majority of the users (all ath9k users) and will help set LEDE apart from other firmwares.
My current position on code names is that they have a place but that they shouldn't be prominently used. Ideally people should refer to "LEDE 17.01.x". The chosen code name will neither appear as part of URLs, nor file names so it is not really important to know from a users pov. You will find it in the version files, and you might encounter it in the wiki but it should not be required to know it.
I always found code names annoying, regardless of whether they're alphabetical or not. A prime example for me is Debian, whenever I look for Debian 8 info, I first have to google the correct code name (was it Jessie or Stretch or Wheezy?) in order to proceed locating the required resources.
This is the wish of some LEDE contributors, but there are varying opinions on that.
+1. Code names don't add information (in fact as @jow mentions, they seem to subtract, if they require you to do a web search to figure out what people are talking about.)
I strongly encourage us to create a name that reflects the year/month the software was actually released, e.g. LEDE 17.01 would have been released in January 2017.
If a release is delayed beyond its previously-determined target (e.g., we think we'll have a 17.05 version but it doesn't go out 'til June) I believe we should name it 17.06
Tastes differ, I personally fins a number that increases very clear, I fried most part of my left brain, and mainly have to do everything in the chaotic right brain, The ubuntu codenames for instance cause a lot of confusion even though they seem to be clear, my rightbrain just turns them into soup with a lot of flavour.
Still i'd say it's all good to have both, A bit for the left brain and a bit for the right.
17.01 would make sense
also LEDE-ONE would work for me
Or in dutch or german EEN TWEE DRIE, EINS ZWEI DREI, Or teach us a bit of Chinese, we might need it if the USA gov. keeps acting like idiots. YI ER SAN
Or maybe in arabic or hebrew? if the font set allows it.
O well, 1 2 3 actually IS the Arabic version allready..
That's my right brained take on this.
Japanese is way more fancy. Almost hipster like 
I humbly suggest the first stable release to be named LEDE いちばん*.
* ichiban
Apologies for pedantry, in my defense: it is getting late here
Strongly supported. Ditch the codename. Only use the date-based designation.
Codename is useful while there's no other designation, but once we get a date, codename outlives its usefulness.
Eh, it's exotic, but I wouldn't go for a japanophile touch, it comes across a bit juvenile and weebish if your project doesn't have a real connection to Japan.
[quote]I humbly suggest the first stable release to be named LEDE いちばん*.
[/quote]
LEDE is number one, the best? A bit presumtuous, no? And there's a good chance that those who have spent significant time in Japan would associate it with a certain chain of curry restaurants. 
And who would understand 「LEDEの始まり」 without punching it into Google Translate? Also keep in mind that LEDE's shell doesn't really do UTF-8 last I checked.
Back on topic, though: After a little time thinking about it, I am just not sure how well the year.month "versioning" will work out with a much more rapid release cycle than OpenWrt had. I mean, OpenWrt had 12.x, 14.x and 15.x, one release a year maximum. It was pretty obvious that there were big differences in between.
But consider a release every three or four months ... We'd have, let's say, 17.01, 17.05, 17.09, 18.02 ... Which one conveys the biggest jump to the uninitiated?
Wouldn't it be better to go to a "rapid version increase" like Chrome and Firefox do nowadays? I mean, it's not ideal either, but it would at least make the releases visibly equal. And with a rapid release cycle, you'd have to check which version is the latest anyway, you probably couldn't always tell from heart like it is now.
(Also, don't take this as strong opposition against year.month, just something to ponder.)
My sense is that the the uninitiated don't care about "the biggest jump" - they become "initiated" when they try out the current release, whatever its features, or its tag. And Chrome/Firefox build numbers change so rapidly that I have lost all track of what they are. I just let 'em update themselves whenever they tell me they want to 
Given our projected release rate of "every few months", I'm attracted to letting the LEDE "build name" convey a notion of how old a particular build is.
If someone writes on the forum saying, "LEDE 17.01 is doing thus and such", we can immediately know that was the initial release, or (if it's now 2019) that this a really old release because it's at least two years old... And you can either refer to your "internal sense" of what stuff has been fixed over the last few years, or can pretty easily check out the specific release notes...
Not what I was getting at. My point is, obviously: 18.01 looks like a "major version bump" compared to 17.12, when in fact it was only a month and possibly just minor changes. Conversely, 17.04 looks like a "minor subversion bump" compared to 17.03 when in fact a lot could have changed in between. The version numbers simple are not version numbers, but look like they are.
We didn't have the issue yet because up until now, OpenWrt releases happened so infrequently that they actually increased the "perceived major version" with every release -- unintentionally.
Come to think about it, it's actually just the dot. Version 1801 vs 1712 (or 18-01 vs. 17-12) would already denote a non-standard major-version.minor-version scheme and make it immediately clear.
OpenWrt/LEDE is really quite exotic in using that year.month release naming scheme as a primary indicator. If there's any other other major software, and we are talking about an operating system here, that handles versions this way I'm not aware of it.
Again, not saying it's bad, just wearing my Captain Obvious hat.
OpenWrt/LEDE is really quite exotic in using that year.month release naming
scheme as a primary indicator. If there's any other other major software, and
we are talking about an operating system here, that handles versions this
way I'm not aware of it.
Ubuntu has been using the YY.MM version for the last 26 releases
OpenWRT did not invent this scheme, it adopted it based on many other projects
making use of it.
David Lang
I think the tongue in cheek was pretty obvious...
I stand corrected, and pondering even more: I have been using Ubuntu before (leaning towards Debian nowadays) and wasn't even aware of it, so in a statistic sample of one idiot that actually proves my point.
ごめんね。You poked one of my sensibilities there.
What seems to be lost in the last 24 hrs of this discussion is the 'dot' release (EG 17.01.0) that is in jow's proposal and the expectation that there will be some quantity of these 'dot's after the initial release (or RC's before). The cycle will take at least a month as proposed by jow so if we expect 2-3 maintenance releases for a branch this will probably take at least 6 months before another branch will grow.
So there likely will not be 17.1, 17.4, 17.8 branches. There will be 17.1.0, 17.1.1, 17.1.2 (the dot referring to nothing but a sequential reference) versions of the released branch. There could be a new 17.9 (September) branch having all the good and bad that trunk brings, but 17.1.2 which could conceivably released in August (8) would expected to be more stable (having only bug fixes and new device support), but potentially not as feature rich.
What is probably more important than the 'numbers' is clear and concise release notes for each release "value" about changes from essentially CC 15.05.1 to the release, and then updating the same document between each 'dot' and future releases. Don't assume the user knows where to look or how to summarize this from bug reports or other sources. Have a link in the same location as the download link to a single document. (There was at one point on the web-site a list of "Why LEDE" that included improved documentation, but I can not find that now).
Regarding RCs, I am not a big fan. 17.1 RC 1 will in effect set the date of January for the release when the actual release (17.1.0) may not occur until April or May and thus not be 17.4. I think it may also discourage some users from adopting until a final release.
well, as one of the 'uninitiated', I have always appreciated the cocktail references in the naming, even shortened as CC or DD ... the recipe I get on logging in remind me of the fact that this project is carried by individuals with their own personal idiosyncracies, and not a bunch of corporate old farts.
I don't care about a 'major jump' - I care about the reassurance that the LEDE/WRT team has done their best to release something to the community which is the best they can do at this point in time.
I understand this is different from someone who has to 'make a living' of this, but don't kill all the fun while you are at it 
(that being said, LEDE does suck, oWRT is a killer brandname - hey, uninitiated 2 (euro)cents)
LEDEの始まり 
nice