On Sun, 7 Nov 2004, Frank Barknecht wrote:

Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:

...

I'm almost ready to stop banging on 0.38, because the changes that seem most urgent now are of a sort that will break a lot of stuff (updating various audio and MIDI interfaces, for instance!)

I think therefore that I should make a 0.38-main branch, so that I can continue to apply "safe" bug fixes to it while I apply the unsafe ones to "main" for incorporation into 0.39.

This way, eventually, we/d have 0.38-main, 0.39-main, etc, branches, along with the current "main" branch which would be perpetually on the path to the next release...

Does this sould like a good structure?

I think, yes. I just discovered the "CVS Best Practices" document at http://www.magic-cauldron.com/ which also recommends something like this at: http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html#section1-branc...

I only wonder, if "main-0.38" would be a better name than "0.38-main", because that would be more in sync with the naming for "devel_0.37" and would allow an easy alphabetic sorting by branch type. However "0.38-main" and "0.38-devel" would allow sorting by development status ...

I vote for calling it main_0.38 (or better stable_0.38 as opposed to devel_0.38). I will try to write down a small document about the "development model" that is in place. What we have currently is some sort of mixture between the standard CVS approach and the linux kernel, which is also developed through patches. Last but not least, we can always rethink the strategy if something does not work they way we want.

Guenter

On Mon, 8 Nov 2004, Reini Urban wrote:

Don't we have "devel_0_37"? So it would stay with the underscores and use "main_0_38" and "devel_0_38". But best practice would be the name "stable_0_38".

Yes, right, "stable_0_38" "best practice" - sounds convincing, have to use it more often :)

Guenter

-- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

Frank Barknecht wrote:

Hallo,

But it's not "stable" yet!! ;)

I still vote for "main" in whatever combination with numbers and unspeakable letters...

i thought the question was how to label branches: miller's release version (to incorporate bug-fixes) miller's development version (to incorporate new features) experimental development (to break old behaviour)

so this would be 3 branches: STABLE_0_38 (release; guaranteed to be stable and bug-fixed) MAIN_0_38 (might be unstable but will become the next release) DEVEL_0_38 (might be unstable and will never become a release; however several features might go into MAIN)

mfg.as.dr IOhannes

...

But it's not "stable" yet!! ;)

I still vote for "main" in whatever combination with numbers and unspeakable letters...

i thought the question was how to label branches: miller's release version (to incorporate bug-fixes) miller's development version (to incorporate new features) experimental development (to break old behaviour)

so this would be 3 branches: STABLE_0_38 (release; guaranteed to be stable and bug-fixed) MAIN_0_38 (might be unstable but will become the next release) DEVEL_0_38 (might be unstable and will never become a release; however several features might go into MAIN)

what about MSP_0_38, since that is, what it is ...

cheers ... tim

On Mon, 8 Nov 2004, Frank Barknecht wrote:

I still vote for "main" in whatever combination with numbers and unspeakable letters...

I think calling a branch "main.." might lead to confusion with the main trunk. Thats why I would call it the "stable.." branch.

Guenter

Ciao

Frank Barknecht _ ______footils.org__

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

Hans-Christoph Steiner wrote:

Ok, this is inspired by the best practices document:

probably i should read it. i'll write this letter first.

Branches: MAIN where Miller maintains his development work on the core release_0_38_patches created after each completed release for bugfixes devel_0_38 created after each completed release for Pd community work

Tags: release_0_38 tagged with each release, before release_*_*_patches is created build_0_39_yyyymmdd tagged with each test release

i do not understand why we would need release_X_YY *tag*s and release_X_YY_patches *branch*es.

the idea of the branch is to get bugfixes in. so i would vote to not tag the release but branch it. bugfixes go into that branch. probably no one is interested in the release *with* bugs.

one would get the stable version (including all fixed bugs) by checking out the tip of the "release_X_YY"-branch.

as for the build_X_YY_yyyymmdd-tags i am not sure either. one can easily check out a branch at a certain date.

as for test-releases, why not keep the habit of naming it test ? like "test_0_39_01" this would most likely be a tag.

Ideally, there would be regular (nightly/weekly) autobuilds so that people working on one platform would know when the broke something on another platform. Also, this would eliminate the work that goes into making test releases. This is a key reason why I have been working on automating builds. And we are not far from being able to do this.

this is ok, but i don't know whether we have to tag for that.

mfg.asd.r IOhannes

I think you should read that first, then post. None of us here is CVS experts, so we should learn from the experts first, then try to decide how to apply it to Pd. This proposal was my attempt at digesting the "best practices" and applying to Pd. As for the branch and tag names, I think we should use the standard names, unless we have a good reason not to.

.hc

On Nov 8, 2004, at 4:08 PM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:

...

Ok, this is inspired by the best practices document:

probably i should read it. i'll write this letter first.

...

Branches: MAIN where Miller maintains his development work on the core release_0_38_patches created after each completed release for bugfixes devel_0_38 created after each completed release for Pd community work Tags: release_0_38 tagged with each release, before release_*_*_patches is created build_0_39_yyyymmdd tagged with each test release

i do not understand why we would need release_X_YY *tag*s and release_X_YY_patches *branch*es.

the idea of the branch is to get bugfixes in. so i would vote to not tag the release but branch it. bugfixes go into that branch. probably no one is interested in the release *with* bugs.

one would get the stable version (including all fixed bugs) by checking out the tip of the "release_X_YY"-branch.

as for the build_X_YY_yyyymmdd-tags i am not sure either. one can easily check out a branch at a certain date.

as for test-releases, why not keep the habit of naming it test ? like "test_0_39_01" this would most likely be a tag.

...

Ideally, there would be regular (nightly/weekly) autobuilds so that people working on one platform would know when the broke something on another platform. Also, this would eliminate the work that goes into making test releases. This is a key reason why I have been working on automating builds. And we are not far from being able to do this.

this is ok, but i don't know whether we have to tag for that.

mfg.asd.r IOhannes

________________________________________________________________________ ____

"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."

- Amy Smith

On Nov 8, 2004, at 4:22 PM, Frank Barknecht wrote:

Hallo, guenter geiger hat gesagt: // guenter geiger wrote:

...

On Mon, 8 Nov 2004, Frank Barknecht wrote:

...

I still vote for "main" in whatever combination with numbers and unspeakable letters...

I think calling a branch "main.." might lead to confusion with the main trunk. Thats why I would call it the "stable.." branch.

I don't stick to "main", "msp" would also be okay, although "main" is more appropriate IMO. But I have a slight problem with "stable". "stable" should only be used after a release. Similar to the way, Debian handles the name "stable", for *the* version to rely on, if you need reliability.

I actually like what Hans proposed in his "best practice" mail: Have "release_x" branches, and release candidates branches (which is the state, 0.38 is currently in).

Actually, the tag "release_0_38" represents the actual release, while the branch "release_0_38_patches" represents the HEAD for the patches to that release, if I understand correctly. That is the reason for the tag in addition to the branch, and also for the "_patches" part, since that branch is not the actual release, but the release plus patches.

.hc

Ciao

Frank Barknecht _ ______footils.org__

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

http://at.or.at/hans/

Hallo, ix hat gesagt: // ix wrote:

i apologiZe for not knowing much C, but is there a way to easily load a symbol (like bluh_setup) under another name? right now my patches are impossible to share without giving a rapidly growing list of things like:

• use my shell external, which happens to have the same name as the one in CVS

This should be easy to fix, by for example renaming your shell? Then $ perl -pi -e "s/shell/myshell/g" *.pd

• use the 'tgrill'-prepend because the CVS-default doesnt have a right inlet

Oh, the tgrill-prepend is called "prepend2" now (or similar). Iemlib-prepend also has a right inlet, Cyclone prepend has a "set X" messge to the first inlet.

• finr/replace in normal prepend to 'makelist' and recompile because tgrill version cant 'prepend list' to a list
• use devel_037 beacuse objectnaming broke the GUI stuff in 038
• make sure you have a dir /s with various sed scripts in it snce you cant enter backslashes in pd..
• make sure you switch to 10pt tahoma or stuff will overlap weird
• make sure you have GNU utils installed an in your PATH on windows

You need to create a bootable Linux live CD. ;)

Ciao

On Nov 8, 2004, at 5:25 PM, ix wrote:

...

...

...

...

with the underscores and use "main_0_38" and "devel_0_38".

what i have just tested (0.37.2 and 0.38test4)

build_0_39_yyyymmdd tagged with each

as for the build_X_YY_yyyymmdd-tags i am not sure either

have you got a 27B-Stroke-6 sir? we can't tag without it...

i apologiZe for not knowing much C, but is there a way to easily load a symbol (like bluh_setup) under another name? right now my patches are impossible to share without giving a rapidly growing list of things like:

• use my shell external, which happens to have the same name as the

one in CVS

• use the 'tgrill'-prepend because the CVS-default doesnt have a right

inlet

• finr/replace in normal prepend to 'makelist' and recompile because

tgrill version cant 'prepend list' to a list

• use devel_037 beacuse objectnaming broke the GUI stuff in 038
• make sure you have a dir /s with various sed scripts in it snce you

cant enter backslashes in pd..

• make sure you switch to 10pt tahoma or stuff will overlap weird
• make sure you have GNU utils installed an in your PATH on windows

(sorry for this, i may need to refer to archive if i format hd or something)

most pressional apps seem to support a 'total recall', keeping all these particularities stored in the project/patch file...

or you could take a cue from microsoft and cxc prepend would be assigned a CLSID of {3050f3B3-98b5-11cf-bb82-00aa00bdce0b}, and pd could just check the master big-brother server to make sure you have the proper version :D

It every Pd user has their own custom setup, then patches will never be easily sharable. This the reason why Guenter, I, and others are working making a "standard" Pd distro. Then it truly becomes a platform to develop on, rather than everything being specific to one person. This is, of course, not without its sacrifices, but well worth it.

And those who want to are always free to build their own custom distro however they see fit. But I think everyone will be better off if we can work towards a common platform. Imagine programming C without a standard libc...

.hc

________________________________________________________________________ ____

Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli