Current Juce Version - please try GIT Version first

#1

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.

So, please consider using the latest code from the GIT repository. This link to juce on sourceforge has some helpful tips and the GIT details needed. http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=summary, or if you already use GIT, then:

Regards,

Bruce Wheaton

#2

Thanks Bruce, that’s a good summary!

#3

#4

Someone want to Sticky it then please?

Bruce

#5

Could you please add a brief description of how to do this svn thing?

Stefan

#6

I added the subversion link from the juce download page to my post. Not sure how to do all the bbcode kung-fu, but it should work.

Bruce

#7

[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.

#8

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!

http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=4352

HTH!

Pete

#9

Hi Jules,
This URL http://sourceforge.net/scm/?type=svn&group_id=137492, has svn command for checking out the source code.

Does it still check out the latest source code from the tip?

#10

[quote=“vishvesh”]Hi Jules,
This URL http://sourceforge.net/scm/?type=svn&group_id=137492, has svn command for checking out the source code.

Does it still check out the latest source code from the tip?[/quote]

…no, the SVN code is now out-of-date, so don’t use it! I left it there temporarily after moving to GIT, but I should remove it now.

#11

I didn’t use it. Wanted to confirm it before using it.
Thanks

#12

I’ve removed it now - thanks for the reminder!

#13

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.

#14

“git pull origin master”, isn’t it?

#15

I just tried that, git said it was already up-to-date (which it may be!) - I’ll try this again after the next update
Ta

#16

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 ?

#17

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”!

#18

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.

#19

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…

#20

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.