I'm gonna blow a gasket, I swear I am

[BigDave]

This whole naming/number/version crap has got the common man confused
about what they're doing. I'm reading the same thing over and over again and
I truly think it's caused a lot of people to think the version 11 Nightlies AND
in some cases the Release Client versions are an UPGRADE from 9.10.2 !!!!!

I'm reading this in posts all over this forum...
"I have upgraded from 9.10.2-U3 to 11-STABLE"

I think that the current 11 update train should have the word STABLE removed
until version 11 STABLE is released, it's causing problems for a lot of users.

 

[joeschmuck]

I agree with you, the Release Candidate should be called "11-RC" or "11-Release Candidate", but to be honest, I can see this would cause issues in the train but maybe this is what is required to maintain clarity.

 

[adrianwi]

FreeNAS version numbering has been all over the place since 9.10, which I believe was used as 10 aka Corral (RIP) was already in development. We've had .dot versions, .dot.dot and .dot.dot.dot, .dot.dot which didn't change but introduced a date, .dot.dot with a Un, not to mention nightlies, RC, Alphas, Betas and I'm sure some I've missed in less than 2 years :o

Hopefully, 11.0 will be a great opportunity to standardise and simplify the version numbering to make it understandable to the general user. It should also align to the version of FreeBSD running underneath.

 

[BigDave]

I agree with you, the Release Candidate should be called "11-RC" or "11-Release Candidate", but to be honest, I can see this would cause issues in the train but maybe this is what is required to maintain clarity.

Well the whole thing is clear to me, but the confusion (as I perceive it to be) is growing. Perform a forum search for "11 STABLE" and see what I mean.

I can see this would cause issues in the train but maybe this is what is required to maintain clarity.

Would you mind expanding on that, I really don't know how the Devs operate.

 

[joeschmuck]

Would you mind expanding on that, I really don't know how the Devs operate.

I believe it would be more work to add another train called "11-Release Candidate" than anyone wants to take on especially since a RC should only exist for a few weeks, ideally. This also means people would have to switch trains from Beta, to RC, to Stable and I've tried this, lately you need to use the CLI to force the train to switch. I'm all for having a RC train but it's not up to me. Maybe this could be used for the next major overhaul of FreeNAS.

 

[BigDave]

Hopefully, 11.0 will be a great opportunity to standardise and simplify the version numbering to make it understandable to the general user. It should also align to the version of FreeBSD running underneath.

I agree 100%, but...
The key words here are "will be".
This is my point, it (FreeNAS 11) IS NOT NOW a STABLE release, but if you look at the GUI,
it appears as though it is.
What you are saying is great when all this gets ironed out, but right now, it's causing confusion.

 

[Stux]

11-STABLE is not so bad. It is stable.

Those who want to wait for release can.

 

[adrianwi]

I believe it would be more work to add another train called "11-Release Candidate" than anyone wants to take on especially since a RC should only exist for a few weeks, ideally.

Surely it would be better to use the nightly train for anything that isn't stable? They could just stop updating it nightly when they'd got to "stable" release (candidate), and updated for each RCn :D

 

[joeschmuck]

Hopefully, 11.0 will be a great opportunity to standardise and simplify the version numbering to make it understandable to the general user.

You are a romantic. Nice thoughts but I doubt anything will change. The one major change that's happened was when the trains were introduced and it eliminated a lot of minor update versions, hence the funny version numbers now.

11-STABLE is not so bad. It is stable.

I think it depends on who you ask. I think it's very close, and then we will have several minor updates to iron that out a bit more. I'm not saying anything bad here, just that it will be a little while before I consider it stable, even if it were rock solid on my machine today. Time proves stability. If I can run FreeNAS and it works flawlessly for 90 days (continuous operation, no reboots, no updates, no memory leaks) then I'd consider it stable until something makes it otherwise. But this is just me.

 

[BigDave]

11-STABLE is not so bad. It is stable.

Those who want to wait for release can.

I'm sorry mate, you totally missed my point

 

[joeschmuck]

I'm sorry mate, you totally missed my point

I understood your point buddy. ;)

 

[anodos]

Perhaps we need 11-STABLE-RC and 11-STABLE-RELEASE

 

[Ericloewe]

I think there's a better fix, long-term: Some additional comments before the list of fixed tickets. That way, the RCs can include a notice about their RC status. It also allows for a whole number of problems with the opaqueness of the process to be solved.

 

[joeschmuck]

I don't think this is a simple fix just because it requires coordination and making a decision to do something. Like I said, hopefully with the next major rollout where a RC would be used, someone will think about this during the early Beta testing and make something happen to make things clearer.

 

[Dice]

I miss a "dictionary" or at least a "in your face" statement that puts all current available versions in a hierarchy enabling users to pick what to get.
It could be fitted as a resource, or better yet in the official manual. Here is a very roughly sketched suggestion.

1. Beta testing. For pro's running experimental machines.
Alpha?
Beta?

2. Off-road. Requires a willingness to debug and report bugs.
-nightlies?
-RC?
<11 "stable"> - insert comments explaining it is actually here, and not in section 3.

3. Stable versions. Tried and test, bump-free ride. Recommended for newbies and production.
9.10-U3

4. Legacy versions:
....other.

Suggest changes as you see fit to each category (I've not paid too much attention to what release fits into which category).
The point of this is to line out quite different categories of stability to users who are ...not accustomed to this type of language.

If there is a corresponding explanation somewhere I've missed, please provide a link for future reference.
However, I still think a "hierarchy of versions explained" would be a nice fit for a resource page.

 

[wblock]

Branch naming decisions are out of my realm, but I did rework the train descriptions in the user guide last week. It now has sections to show which are for production use, and shows the preferred trains first. There is more to be done here.

 

[Dice]

In section 5.8.2 my suggestion above is pretty much dead on there. Good!
Now let's remember to remind users on where to find that bit of information.

IMO the priority should be to somehow downplay the availability or appeal of other than the version that is immediately available on freenas.org. To me that is a fair metric on what is considered stable enough. The RC, nightlies and what else have you ...should be somehow framed a little less appealing in the eyes of FreeNAS newbies.
As a starting point, I feel since the time Corral became "sort of available" there has been a huge upswing in newbies posting problems which ...probably would've been avoided if a more conservative upgrading pattern would be the norm.
When I started lurking the forums 2 years ago, there was a lot stronger "wall" directing newbies away from Nightlies and ...pretty much anything else than the STABLE version. I don't see that quite as much today, judging from the activity in the forum. Do you agree?

 

[wblock]

Unfortunately, we are in a weird position now due to both the Corral situation and version numbering. It will be better soon, after 11 is released.

Part of the motivation to rework those trains descriptions was that it wasn't obvious which were for production use. That's better now. There's a limit to how much good we can do in the docs, because some people always have to have the latest regardless of whatever warnings come with it. On the other hand, testing in the wider community does a lot of good, too.

We could probably improve the way update trains are shown on the screen, or add some warnings when people go from production use branches to experimental ones. Suggestions are welcome, particularly ones we can turn into actionable bug reports.

 

[Redcoat]

Seems to me that BigDave's suggestion to remove "STABLE" from the 11 train description would eliminate significant opportunity for confusion, also meeting Dice's last paragraph comment.

 

[Dice]

There's a limit to how much good we can do in the docs, because some people always have to have the latest regardless of whatever warnings come with it. On the other hand, testing in the wider community does a lot of good, too.

My previous comment should be read as referencing the wider community, not the documents & official stuff mainly.

I think what I see is something along the lines of the saying "..oh you know, kids these days... " referring to everyone wanting the <latest> without regards to what <is stable enough> or perhaps more strikingly <fitment to skill, ambition and scope> of their FreeNAS experience.
Coming from other "windowzed" closed source environments it is quite the leap to suddenly be able to just scroll down a menu to get <cutting edge technology> ...without really understanding what it implies. Ie, the extra work and commitment that route requires. For someone well familiar with *nix, open source and communities, it might come less as a "shocker" but I think the FreeNAS product and appeal has outgrown itself from the *nix tinkers up to a wider audience, who does not carry some implicit understandings.
My point is to sort of point out that something along these lines is morphing. The community, as well as the forum would benefit from some set point which <lays out> the text a little bit on what is <expected>. There probably are texts written about this in the past too. However, I think there is some benefit to be had from additional efforts on clarification.
The million dollar question tho, where would it be fitted to have newbies actually read ?

We could probably improve the way update trains are shown on the screen, or add some warnings when people go from production use branches to experimental ones. Suggestions are welcome, particularly ones we can turn into actionable bug reports.

I agree with @Redcoat that is just what @BigDave puts forward. That should be a simple step (for whomever has authority).

Adding to all of my rants on the topic, I'd say that a <opensource newbie primer> of what beta-testing is about, bug reporting, community contributing etc would be most welcome. It should include the different layers of FreeNAS versions (as touched upon in the docs as of now), but also make quite clear that -don't run Nightlies, RC etc if you are not prepared to do actual bug reporting and "contributing testing" in various ways. If that does not sound appealing to <the newbie> it should be clear what version to use.