Maintenance Branch for Latest Release (1.11.x)

[abbotware]

I am not sure what your branching strategy is, but from what I can tell, the latest official release of flatc is 1.11 and I do not see a branch for 1.11 in the list of branches.

Considering that the flatc generated code must use library code that is provided by the flatbuffers project, it seems like best practice would be to create a maintenance branch so the library code and auto generated code can be kept in sync.

for the C# code, right now version 1.11 of the flatc tool is incompatible with the the main branch. I have no easy way of knowing (without digging into the source history) where to locate the compatible C# code for 1.11.

Please retroactively create the branch, if you know what is the correct commit version to use.

[abbotware]

OK - I see a 'Release Tag' for 1.11 exists - with the bundle of code - but I still think a maintenance branch is good practice

[dbaileychess]

Is your issue that you generated code using version 1.11 and are now using those files with the top of master? The easy solution is to regenerated the the code from the schema using the latest code.

[aardappel]

Yes, this project doesn't do any branching so far.. we've never patched major versions after the fact, only fixed it forward with a minor version on master once.

Generally, our major version numbers aren't any different from any other commit, really. They're just there for people who prefer pinning to versions rather than commits. I'd recommend any project to just follow master instead as best they can.

[abbotware]

They're just there for people who prefer pinning to versions rather than commits. I'd recommend any project to just follow master instead as best they can.

Why would I use master when I have no idea if it even builds or is even stable? (it currently says build failing) .

Aside from the small amount of library code, flatbuffers seems more like build / tool chain related binary... Why would I want to build it from source? It seems more natural to use it as executable.

I think it would be best practice to use officially released binaries for the compiler and library code than unknown code / status.

I can understand if this is a bit more work (ie setting up packages for different OS, Platforms, publishing, etc)

For comparison... take a look at this project :-)

https://github.com/protocolbuffers/protobuf/releases

and

https://www.nuget.org/packages/Google.Protobuf/

The first link is the compiler, the second link is the library :-)

[aardappel]

Why would I use master when I have no idea if it even builds or is even stable? (it currently says build failing) .

There is no stability difference between a numbered release and any other commit. Yes, CI breaks, and we do releases when CI is green, but you can pick those yourself too.

Aside from the small amount of library code, flatbuffers seems more like build / tool chain related binary... Why would I want to build it from source? It seems more natural to use it as executable.

Because the build tool and the library code have to stay in sync, and you guarantee that by building the tool.

For comparison... take a look at this project :-)

I don't think you understand how much more headcount a project like Protobuf has :) We need to keep things simple. If you want to help out by making our CI generate official binaries automagically, you're very welcome :)

[mjvankampen]

A CI to build your binaries is already in place, something Conan takes care of for you! So instead of releasing a million binaries like protocol buffers people should just use Conan imho, you can even use that to just download the binaries with a guarantee that they match to your platform and compiler.

For me the added value of releases is to have something that is easy to refer to and has a changelog. In addition new releases will be picked up by Conan and allow semver instead of dates or commit hashes (if there are more commits on a date) which do not give you a lot of information.

In addition I guess more people need to move from protobuf to flatbuf 😄

[aardappel]

This appears to have packages for every commit id: https://bintray.com/aardappel/flatbuffers/flatbuffers%3Agoogle
The tgz contains binaries, which I assume are Linux 64-bit of some variety.

Not exactly the friendliest format though :)

[mjvankampen]

So you could use that repo to get packages and have conan sort out the format (makes it friendly for you), but not for every commit, only 1.10 and 1.11, but many pre-compiled binaries.

This means no CI is needed (community/conan/bintray takes care of that), but semver releases are still required. You only get the newest stuff if a new release is done. There needs to be some indication which version is newer, which a commit hash does not tell you. If there are no releases anymore then conan (and bintray) should maybe switch to a date format, but I always prefer releases with a short changelog.

@aardappel Do you still plan to do releases? I know I would at least appreciate it!

Ps. excuse me for the off-topic discussion, but I agree that branches are not necessary. I just think following the latest commit is not the most friendly version of consuming flatbuffers. A tagged commit makes life a lot more easy.

[abbotware]

@mjvk - I think branches are necessary - if a CVE is reported - how would that be addressed / fixed?

[aardappel]

@mjvk yes I still intend to do releases.. I'm aware we're overdue for one.

[mjvankampen]

@abbotware I think the philosophy now is that the user should switch to a newer version of flatbuffers, so from 1.10 to say 1.12 where the CVE is not present. For now, as I understand from what aardappel is saying, is that there is no plan to do fixes like that as there is nothing breaking in the newer versions. I can imagine this might change when a flatbuffer 2.0 would be released.

In my own projects I only create a maintenance branch when I need one (i.e. a fix is released), release branches are deleted. So if I never update an old release I will only have a master branch (and develop depending on the project), and that works fine tbh. This prevents quite a bit of clutter in my opinion as we don't support every old release, especially if it is already fixed in a newer, non-breaking release.

@aardappel That's a relief, I must have misunderstood you there.

[github-actions]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.