On Fri, Sep 2, 2011 at 6:23 PM, Joe Emenaker wrote:
> 3a) Branch off 2.0 and let bug-fixing happen there while new features
> and development toward 3.0 happen in trunk.
> 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes
> for 2.0 happen in trunk. When 2.0 is released, a tag
On 09/02/2011 05:18 PM, William Zwicky wrote:
> On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker wrote:
>> Once I finish this refactor, the next thing I want to set to work on is
>> making it so that drivers can be loaded as plugins. This will allow us
>> to *not* have to make a new release of JSL in
On 09/02/2011 10:13 AM, Vladimir Avdonin wrote:
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment.
That sounds like you're saying that, at all times, checking out from
trunk should give you a release. That's differ
On Fri, Sep 2, 2011 at 7:59 AM, Vladimir Avdonin wrote:
> Hey, please do not hide you development. The branch does not need to be
> tidy and compilable. You could dump your work in progress freely on it.
> This way other developers would be able to plug in early. I for one is
> looking forward to
On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker wrote:
> Once I finish this refactor, the next thing I want to set to work on is
> making it so that drivers can be loaded as plugins. This will allow us
> to *not* have to make a new release of JSL in order to get a new driver
> out to the world.
>
W
On Fri, Sep 2, 2011 at 10:13 AM, Vladimir Avdonin wrote:
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment. The only
> commits that shall go there should be from tested working branch.
> ...
> What if we do not wa
> it shall stay clean and functional at any moment.
If only clean stuff is commited this would still be possible.
> What if we do not want to go back? Breaking up things is inevitable in
> process of changing. And broken period can take extended time.
We could still use a refactoring branch.
On 09/02/2011 11:57 AM, Joachim wrote:
> Ah, I don't think it makes sense to make a branch for every bug.
Not every bug, just complicated ones, involving non-obvious changes and
requiring extensive testing
>
> > and it might be not clear at start towards what release it
> > will be targete
Ah, I don't think it makes sense to make a branch for every bug.
> and it might be not clear at start towards what release it
> will be targeted
The target release is not a problem if the development takes place
in the trunk.
> it probably would break everything in the project
Remember: We c
Sounds to me like the mimetype is not the problem but a binary flag is set.
I'd say you may try it. If it doesn't work you can still go back to the
current revision of the file.
Cheers
Joachim
Am 02.09.2011 18:27, schrieb frankster:
> I ran into that problem and got around it by using the --force
On 09/02/2011 11:25 AM, Joachim wrote:
> Hi,
>
> > I could think of three directories: fixes, features, users.
>
> Normally branches are made for different releases. I don't see
> a benefit in these three suggested branches as bug fixes have to
> be merged with new features anyway. The users bra
Changed the default download to the 0.20 dmg for Mac and
the jar for all other plattforms.
Thanks for the heads up!
Cheers
Joachim
Am 02.09.2011 15:46, schrieb frankster:
> I noticed on the project page
> (https://sourceforge.net/projects/jsynthlib/) that the download button
> goes to CAProvider
I ran into that problem and got around it by using the --force argument.
But taking the attribute off would also be good IMO, its not like it
contains any binary data blobs or anything.
frankie
On 09/02/11 17:15, Vladimir Avdonin wrote:
> Hey,
>
> Is anyone else having problem not being able to
Hi,
> I could think of three directories: fixes, features, users.
Normally branches are made for different releases. I don't see
a benefit in these three suggested branches as bug fixes have to
be merged with new features anyway. The users branch is a concept
I didn't get.
trunk is the somehow
Hey,
Is anyone else having problem not being able to diff build.xml from svn
clients. I get this error:
$ svn diff -r 1094 build.xml
Index: build.xml
===
Cannot display: file marked as a binary type.
svn:mime-type = application/xml
On 09/02/2011 09:38 AM, Joe Emenaker wrote:
> 1 - Will we want to manage the source for JSL and the drivers
> *separately* at that point? Would we have a branch for every driver, or
> have a branch for*all* of the drivers? Or is there a better way to do
> this than to use branches?
I would think
On 9/2/2011 5:22 AM, frankster wrote:
> It seems to me that as there are several extra synths supported since
> version 0.20, it would be worth getting some kind of release out
> (perhaps alpha quality / unstable version), so that people can make use
> of the work people have done over the last 6 y
I noticed on the project page
(https://sourceforge.net/projects/jsynthlib/) that the download button
goes to CAProvider.jar. And if you click on the files button, it goes to
a screen with 3 jar files and a message at the top: "Looking for the
latest version? *Download CAProvider.jar (11.7 kB)
On 09/02/11 12:38, Vladimir Avdonin wrote:
> Frankie:
>
> I was planning to apply my patch for sy77 on a separate branch once I
> get svn access from Joachim. And from there I was thinking to
> investigate how to make a pre-built binary available for download at SF
> for anyone with actual hardwar
On 09/02/11 02:06, Vladimir Avdonin wrote:
> On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>> Okay, I think I understand Subversion enough to be dangerous.
>>
>> I'll need to make a branch to upload my refactored version to. All of
>> the branches seem to be named after version numbers, but my
>> un
Frankie:
I was planning to apply my patch for sy77 on a separate branch once I
get svn access from Joachim. And from there I was thinking to
investigate how to make a pre-built binary available for download at SF
for anyone with actual hardware willing to test.
But in general synth drivers are
So last night I've put in 2 patches that I made, and 2 patches that
other people made. They were all quite small patches and it was possible
for me to test them all. There are (at least) 3 more substantial patches
available that its not really possible for me to test as they are
drivers for har
22 matches
Mail list logo
