Renaming to community sounds good. But if you are going to fork (i.e. make structural changes, IMPd, etc.) then it seems that we should have a distinct fork branch, and a devel branch. devel would be for adding changes to miller's version and the community/fork branch would be separate.
Or it'd probably make the most sense to keep devel as a branch, then make the "community" fork its own directory. If the idea is to make major, incompatible changes then keeping it a branch doesn't seem to make a lot of sense to me.
.hc
On May 10, 2005, at 10:05 PM, Mathieu Bouchard wrote:
On Sun, 8 May 2005, Thomas Grill wrote:
In my opinion Miller's vanilla PD is more like a development version in the way that it introduces more fundamental changes to the structure, while the devel branch normally just adds convience features.
This is going to change. The devel branch will introduce more fundamental changes to the structure. The reason why no-one has really been daring to is because it's too much trouble to repatch every devel version of PureData this way:
miller-0.37 ---fork---> devel-0.37 | / | | / | | / merge evolve .--obliviate--' if you | / care | / | v v v miller-0.38 ---fork---> devel-0.38
That is, currently, a new devel version is the last released miller version plus part of the diff between devel 0.37 and miller 0.37. The diagonal arrow is for the most part a non-arrow; to be fair, it's a "merge" arrow but with a small percentage, whereas devel 0.38 has all the new features of miller 0.38. Basically the same thing happened between 0.36 and 0.37 (but I wasn't really in the team yet, so correct me if I'm wrong).
What I would see for the future is this:
miller-0.38 ----fork-----> community (formerly devel-0.38) | / | | / |----fork---> community stable R1 | whatever / | evolve .-- miller ---' evolve | / wants to do | | / |----fork---> community stable R2 v v merge v miller-0.39 --- if you ---> community | care | etc etc
Note that there are no version numbers for devel anymore. Here I renamed it to "community". This system supports major changes in the community branch, and no-longer supports the primacy of the miller branch. The community branch would have its own stable releases independent from the miller branch; they would be numbered differently so that there would be no confusion _and_ that the miller-0.xx.0 releases *don't* drive version changes of the releases of the community branch.
but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon.
There is still no such indication for SIMD, and it will get worse when ImpureData enters the picture, which is Real Soon Now (tm).
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
To my knowledge this has always been the case, no?
Does the long explanation above answer your question?
,-o---------o---------o---------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'_______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore