This is my first post in this forum, but I have been an extremely happy JUCE user for 6+ months. Please forgive me if I'm asking a question that I could have found the answer for elsewhere. Please consider this post as an attempt to understand the development process of JUCE.
I am a experienced git user and am currently using the tagged version 3.1.1 from github for my project's master branch (production code) and have a local development branch for my project, which uses the current master branch from github. This is intended to make sure I only have stable versions of JUCE in my master branch. Is this the preferred way to do it, the JUCE way? Meaning, are the tagged versions considered stable - or is everything in the master branch of JUCE stable enough to be used for production code?
It seems that there has been no tagged version since v3.1.1 from Dec 16, 2014, but a significant number of commits (330+) since then. It is difficult to make out of the individual commits on github what exactly is being worked on. Is there a webpage somewhere which lists these things, and things like breaking changes etc.? Or should you watch release notes (where should I find these), or simply read every single commit?
So to sum it up, my questions are:
- Is the master branch considered stable?
- Are releases/tags considered stable? Where to find release notes?
- Or, is it left up to ourselves to do the testing and management of breaking changes? :)
Thanks for the wonderful work done to make this library what it is. I will for sure be a paying customer in the near future.
Now that we have a team working on the same repo, we're fine-tuning our internal procedure regarding branches and tagging.
But the main policy that you need to know is that we'll never push anything to the master branch if we're not confident that it will be safe to use. Any development requiring multiple commits will happen on our own local repo in a branch, and when we're happy that it's ready for the public, we then push it to the public repo.
That doesn't mean that the bleeding-edge has been fully tested! But since any bug-fixes go into it, it is certainly the place where there are the fewest known bugs. And for other projects that I'm involved with, e.g. other ROLI projects or Tracktion, these do all link to the bleeding edge.
Wow, I heard about JUCE's great support, but this even exceeded my expectations.
Thanks for the valuable explanation. It makes total sense to do it this way, and I am happy to be able to more confidently use the juce master for my daily development, as this will definitely shorten the process between bug fixes / new features and end users being happy.
The split between development, beta and production branches is happening at our end in any case, but knowing to be able to trust the bleeding-edge as you do yourselves internally, definitely makes for a more agile and fun development process.
I will subscribe to the General News forum, as I expect that to be the place to be updated about major releases/changes.
While clearly (as Jules indicated) they don't intentionally break the tip, that is not the same as the tip being "stable" by any conventional definition. If you have one or two projects that rely on JUCE, continuous integration against the tip might work just fine for you. If you have multiple projects that build against multiple SDKs, trying to manage any kind of testing/release process when your underlying libraries keep changing out from under you can be absolutely maddening (considerably less so if you are the maintainer of said library).
Releases/tags have not necessarily been a useful indicator of stability either.
http://www.juce.com/forum/topic/git-tags
This is one of the top priority requests for improvement I've communicated in the recent JUCE questionaires and here in the forums - if you share a desire for more meaningful versioning and a workflow that separates stable (release) and development (tip) branches, please speak up so that the JUCE team can allocate their efforts appropriately.
I should also have added that we'll continue tagging "stable" release points in the future, so people may want to stick to those. And we may switch to a develop/master branch system, that's something we're discussing at the moment.
tipically master branch accepts bugfixes on the new release, new features get developed in local or remote branches only (when they are big) and pushed to master once tested, tags should mark releases so one can tight a software to specific versioning… that’s the way of doing things… please don’t do a separate develop branch, don’t keep master as the last stable release, and please don’t forget tagging releases for months…
