I’ve made a cursory review of the GoogleCode commit logs, looking for changes suitable for backporting to the 3.0final branch for the proposed 3.0.6 patch release.
I’ve identified the following functional changes as candidates – mostly simple, low-risk bug fixes to Engine features not related to platforms or the blender importer:
10768 plug descriptor leak in binary importer/exporter
10769 plug descriptor leak in AbstractHeightMap save
10771 reset planeState and viewportChanged for a cloned camera
10774 plug descriptor leak in Natives.computeNativesHash()
10780 correct WaterFilter parameter name
10820 fix for TestMusicStreaming crash
10821 fix for Nifty mouse click
10832 fix shadows post-pass when caster is removed
10843 remove diagnostic println from SpotLight
10885 fix FilterPostProcessor re-initialization
10899 fix camera parallel to plane of simple water
10904 fix NaNs when merging bounding box with infinite sphere
10931 exception in SpotLight
10937 fix alpha falloff in LwjglRenderer
10938 fix alpha falloff in LwjglRenderer
10943 reinitialize BloomFilter on downsampling change
10945 fix NPE in FlyCamAppState
10993 fix for parallax mapping
10995 fix for animControl cycle done
11032 fix BatchNode.clone()
11055 attenuation in LightScatteringFilter
11063 avoid deprecated GLSL function in ShaderLib
11074 fix issue #614 (name of SYSRQ key)
11076 fix issue #615 (backward Dome normals)
11078 fix issue #613 (ClassCastException during read)
11080 fix Mesh.deepClone() sets wrong elementCount and vertCount
11082 fix issue #622 (FlybyCamera zooms to negative FOV)
11083 exception in KinematicRagdollControl
11095 fix issue #631 (MeshCollisionShape constructor requires a triangle mesh)
11097 fix issue #556 (StatsAppState.setFont() visibility)
11107 fix issue #637 (load ICO asset from JAR)
Plus a reminder to update JmeVersion and plugins.version!
If it’s OK to include documentation fixes, then I’d also suggest the following:
10824 javadoc for Spatial methods
10831 javadoc for AudioNode
10900 javadoc for Node.attachChild
10901 javadoc for SkyFactory
10902 javadoc for DirectionalLight
10903 javadoc for EdgeFilteringMode
10912 fix issue #552 (javadoc for AbstractCinematicEvent)
11025 comment in LwjglRenderer
11090 javadoc for AbstractShadowRenderer
Generally speaking and from my point of view:
Minor patches should NOT alter the api itself. It might be ok if only internal api is changed. Nothing sucks more than updating to a new minor version and having to changes your code.
Haven’t looked at all those patches, so i don’t know if one of those modifies the api
//ADD:
Beside that, having to add handpicked bugfixes manually in two branches smells like a flawed branching model.
@zzuegg said:
Generally speaking and from my point of view:
Minor patches should NOT alter the api itself. It might be ok if only internal api is changed. Nothing sucks more than updating to a new minor version and having to changes your code.
Haven't looked at all those patches, so i don't know if one of those modifies the api
//ADD:
Beside that, having to add handpicked bugfixes manually in two branches smells like a flawed branching model.
While what you say about the minor updates is correct and we always do it that way, who wants to apply to two branches? This will get merged to the stable svn branch from svn trunk, then the stable branch will be merged in the copy in git. They are the same branch and it doesn’t have to do anything with a “flawed branching model” but simply with our move to github. After 3.0.6 svn will be completely dormant and 3.0 stable will live on in the github 3.0 branch for any future 3.0.7’s etc. Obviously updates for a stable branch should be hand picked!
@sgold: Awesome initiative, sounds like you already kept out the ones that depend on other changes that cannot be merged, for example the blender importer stuffs. I’ll go though the list when I have time, I guess the other core devs will, too. Thanks a lot!
@normen said:
This will get merged to the stable svn branch from svn trunk, then the stable branch will be merged in the copy in git.
I don’t know what your future plan are, but that already sound’s like it could cause trouble if you ever plan to merge the git-master to the git-3.0 at some point later.
@normen said:
Obviously updates for a stable branch should be hand picked!
From my point of view a clear no. Bugfixes should not be handpicked. At least not from the point when you don't have to maintain two SVC's.
At least on my private repositories, the only allowed operation to a stable branch is a merge from the bugfix branch.
I don’t know what your future plan are, but that already sound’s like it could cause trouble if you ever plan to merge the git-master to the git-3.0 at some point later.
From my point of view a clear no. Bugfixes should not be handpicked. At least not from the point when you don’t have to maintain two SVC’s.
At least on my private repositories, the only allowed operation to a stable branch is a merge from the bugfix branch.
So how you get changes from the development branch into the bugfix branch then? You just have one more (useless) repo in your example. We put the bugfixes directly in the stable branch.
3.0 stable will always be 3.0 stable, with no api changes merged so people can for all eternity compile the projects they are doing now. So it would not make much sense to merge master into 3.0, there will be a new 3.1 branch made from master. You seem genuinely confused, check our blog entry for an explanation how the versioning works: http://hub.jmonkeyengine.org/2011/10/jmonkeyengine3-sdk-beta-released/
@normen said:
So how you get changes from the development branch into the bugfix branch then? You just have one more (useless) repo in your example. We put the bugfixes directly in the stable branch.
Eighter i am missing something, but that sounds like you have to apply a bugfix in the stable and the master?
My bugfix branch is continuously merged with in development (i want the bug’s fixed in future versions too). In case of a new release, develop gets merged back to bugfix, and bugfix to stable.
@zzuegg said:
Eighter i am missing something, but that sounds like you have to apply a bugfix in the stable and the master?
My bugfix branch is continuously merged with the development of course (i want the bug's fixed in future versions too). In case of a new release, develop gets merged back to bugfix, and bugfix to stable.
We fix bugs in our master branch and merge it to stable, like any sane person. Again, how do you get your fixes into your fix branch? Do you copy-paste everything to both the master and bugfix branch? And you don’t keep a branch for earlier release versions?
Earlier stable versions are basically only a snapshot in case of a new stable release. No more changes on that beside some really critical once.
No, i bugfix stuff directly in the bugfix branch. Why should i fix against a future version? Lots of other changes could have happend that influences the outcome.
I fix against my stable version.
@zzuegg said:
Early version are basically only a snapshot in case of a new stable release. No more changes on that beside some really critical once.
No, i bugfix stuff directly in the bugfix branch. Why should i fix against a future version? Lots of other changes could have happend that influences the outcome.
I fix against my stable version.
So you fix in the bugfix branch and merge to master and stable? Sounds more complicated than fixing in master and merging single commits to stable ^^
@normen said:
So you fix in the bugfix branch and merge to master and stable? Sounds more complicated than fixing in master and merging single commits to stable ^^
Yeah, it sounds complicated, but it is not.
I find it more complicated to look trough a whole bunch of commits, picking the bugfixing once, making sure no api has changed, and commiting those to stable. Also i am 100% sure i am not missing a a commit…
Beside that, the merge to stable is guaranteed to work without any conflicts so it is easy to automate
//Describing my approach made me really think about it because it really sounds more complicated than it is.
BTW, sorry for the spam wave, there is no way github doesn’t send an email if you open a issue
@zzuegg said:
Yeah, it sounds complicated, but it is not.
I find it more complicated to look trough a whole bunch of commits, picking the bugfixing once, making sure no api has changed, and commiting those to stable. Also i am 100% sure i am not missing a a commit..
Beside that, the merge to stable is guaranteed to work without any conflicts so it is easy to automate
Right, so you have an approach you like, we have one that we like, none of which is “flawed”.
@zzuegg said:
Yeah, it sounds complicated, but it is not.
I find it more complicated to look trough a whole bunch of commits, picking the bugfixing once, making sure no api has changed, and commiting those to stable. Also i am 100% sure i am not missing a a commit..
Beside that, the merge to stable is guaranteed to work without any conflicts so it is easy to automate
//Describing my approach made me really think about it because it really sounds more complicated than it is.
A bit off-topic but; Yay branching model I recognize We use a similar at daytime work, it is actually pretty nice. We even do “feature” branches for most dev-changes, so not a lot gets committed to master, rather it gets merged to master from feature branches (pull requests makes code reviews easy). Yes there is a bit of overhead with all the branches but mostly it is automated.
It actually isn’t all that different from how the workflow was in SVN but instead of looking at patch-files and decide if you should commit or not you look at a pull request from another branch to decide if it goes in or not.
@zzuegg said:
Generally speaking and from my point of view:
Minor patches should NOT alter the api itself. It might be ok if only internal api is changed. Nothing sucks more than updating to a new minor version and having to changes your code.
Haven't looked at all those patches, so i don't know if one of those modifies the api
I tried to omit changes (like 11088) which alter existing APIs in a potentially incompatible way. However I wasn’t super strict about not changing APIs. I did include at least one change (11097) which increases the visibility of an existing method and another (11032) which overrides an existing method.
