I submit that something like this go in the sticky section:
Although a stable release of Juce is available as a download package, Juce is an evolving class library, with rapid bugfixes and incremental improvements.
As opposed to many projects, where the source control ‘tip’ is the bleeding edge, and used mainly by the internal developers, the Juce tip is generally stable, and can be used as the base for new projects. Using it will minimize the number of problems you find, and make it easier for other users to help you, as most of us - AFAICT - are working on a very current version.
Juce is primarily created by one developer, with feedback from many users, and Jules tends to only commit code changes that he has checked thoroughly, and he documents the less tested areas as they get added.
[quote]
Could you please add a brief description of how to do this svn thing?[/quote]
Seriously ?
Get for example “Versions” software (for Mac), or SmartSVN, enter the https://scm… the log is Juce, no password, read only. You can get it with your terminal directly.
Then compile Juce, each time you make an update from the SVN just recompile.
SVN is useful for at least 2 reasons : 1. you dont have to do unpack or so on and localisation is made one time for all, 2. you can trace the changes in API
SVN is something you quickly should get in mind, for collaborative coding or tools/app publishing.
Just to bring this sticky thread up-to-date… Jules has now moved the repository from svn to git … so if you want the latest Juce code, you need to use git rather than svn!
I’m using git (bash) but I’m not convinced I’m being all that efficient - I use the command shown on the Raw Material’s web help page, and it works, but is there a succinct bash command forjust updating the latest changes (without re-downloading everything every time)? - I’m sure there ought-to-be, but it doesn’t seem to be as straight-forward as it was with SVN.
What is the best practice : keep getting the latest juce’s version as you develop, or use freeze the juce’s version number ?
I’m thinking of keeping juce regulary updated. I know there is always a probablility of regressions and/or backward compatibility breaks, however, it seems quite low with juce. What do you guys think/recomend ?
It’s up to you really. The tip is generally pretty stable.
The only thing I’d ask is that any bug reports are refer only to the tip - it’s very annoying for me to spend ages discussing a problem and then be told “oh, sorry, I was using an old version, and it looks like you actually fixed this months ago”!
Hi Jules,
I can understand it can be very tough and annoying( I am a guilty party in this). The simplest solution for this would be to make it mandatory for everyone to post their juce version, whenever anybody raises an issue or use Bugzilla or some other tool for logging bugs in juce. That way we could have lists of issues fixed which others can go through and check if the issue they intend to log is fixed or not.
[quote=“dinaiz”]What is the best practice : keep getting the latest juce’s version as you develop, or use freeze the juce’s version number ?
I’m thinking of keeping juce regulary updated. I know there is always a probablility of regressions and/or backward compatibility breaks, however, it seems quite low with juce. What do you guys think/recomend ?[/quote]
It all depends on how often you plan to update your code. We had a issue wherein our product was using juce 1.39 and it took me more than a year to convince my former Project Manager to upgrade to latest version of juce(Snow leopard issues came in very handy.) We tried to move the application to juce 1.50 it took us nearly couple of months to get it working and the testing process is still on. It might take more time. Since juce has changed a lot in that time.
It is not feasible to upgrade juce everyday. The best thing to do would be to upgrade every 15 days or for every release. That way changes would be less and regression bug any, will be very few. But again it all depends on how often you make releases.
Yes - posting exactly which version you’re talking about would be a very good suggestion!
I’m quite happy to answer questions like “has xyz been fixed since version 1.49?”. That’s no problem at all, (assuming I can remember)
The ones that are aggravating are where someone persuades me to go and investigate something, and then after wasting a lot of time trying to figure it out, I realise that they’re talking about an entirely different codebase… Grrr…
Of late there have been lots of changes in juce(at least on Macintosh), It might be hard for you to remember all the changes. I think you should consider having some mechanism for listing the issues.
