Good morning, > For the future, i would like people starting to put ALL changes (minus > the ones that clearly and intentionally only belong to stable) to trunk > first, and merge them to the stable branch afterwards. While the other > way round is equal on the functional side, i think it's psychologically > better to do it this way. And it prevents regressions in future > versions, because even if some change is not merged by accident, it will > hit at least the next stable branch. Well, good idea but I think trunk and drifted to far apart to manage this.
As a first shot I would assume we copy the stable to a "new trunk" and merge all the stuff from the current trunk that is not intended for 1.0 again. Then trunk and branch are more related again as they are now. > Additionally, i hope that the commit messages for merges will be more > meaningfull in the future. For whole changeset merges, i think of > something like: > > "Merge whole changeset [1234] from trunk: > > Added Feature A > Added Feature B > Added Feature C" Full ACK. > Or we just switch to some more advanced source code management system > that is able to track merges for itself, but i'm not eager to reiterate > this discussion now. I don't think we need to do so. More discipline with applying patches should be enough. And yes, I think I committed a lot stuff without this discipline yet and directly to 1.0. mea culpa. /Markus
signature.asc
Description: OpenPGP digital signature
_______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
