[Fury]

Since original topic was locked and I wanted to comment on the topic.

It's a good move to depart from FSO release schedule for numerous reasons of which FSU devs are already aware of, but I would also suggest dropping current release numbering if that comes to pass. There's little sense in keeping FSO release numbering if FSU release schedule is no longer (loosely) tied to FSO's. One based on date could be ideal, like in MM.YY format. Mediavps released now would then have 8.11 version number. If update is released, it'd be 8.11.1.

Just a suggestion.

[Aardwolf]

I would go with YY.MM instead; that way the order of versions is intuitive. I mean, if you saw versions named "8.11" and "3.12", which would you assume was more recent?

[Fury]

Point.

[sigtau]

I would go with YY.MM instead; that way the order of versions is intuitive. I mean, if you saw versions named "8.11" and "3.12", which would you assume was more recent?

This.  Although if the Media VPs are utilizing any new features found in the nightlies, they don't really have a choice but to wait on the next FSO release candidate, do they?

[rscaper1070]

That would be pretty simple to keep track of and you just wouldn't release those bits until the code caught up.

[Zacam]

Please note, I'm only saying that for THIS release, we are not looking to bind ourselves to Releasing an incomplete package to coincide with an FSO release.

I wasn't suggesting that the FSU was doing away with "Synchronized" or Versioned to FSO Build releases, just that in this case, we're likely to be skipping a revision.

But we'll be having conversations internally on how we'll proceed on future releases, so it is still an open topic as long as it doesn't diverge into a "wish list" or speculation of what is coming thread.