19/08/13 22:28, intrigeri wrote: > Hi, > > anonym wrote (19 Aug 2013 12:24:46 GMT) : >> Or have I missed something obvious? > > How about we use on 0.7.16.1 for the next point-release's l10n > updates, and keep 0.7.17 for the next major release (with your new > feature in)? This way, 0.7.17~$N >> the version in the point-release. > > If we go this way, perhaps it's time to change t-g's versioning > scheme, and e.g. go for 0.7.17 (point-release) and 0.8 (targeted at > the next major release). > > What do you think?
It definitely sounds like an improvement. However, I can also foresee issues when merging diverging snapshots of the same bundled package into Tails' devel and experimental APT suites. The core of the problem is that our bundled .debs are separate from our Tails git which complicates our merge based work flow; after all, .debs in our APT suites cannot be merged, they just replace one another, so an APT suite merge may in fact remove functionality unlike a properly handled git merge. This could be especially problematic in experimental: a bundled package can be replaced before it has been reviewed, and depending on what the branch is about (imagine one that doesn't change functionality, like a refactoring branch), it may get merged without its code actually having been tested, because "testing looked good". This could bring some nasty surprises for the RM at release time. For devel and stable the same applies, which is less problematic, but it means they would intermittently be in states where they don't have all functionality that's supposed to have been merged into them. Maybe our bundled packages' git repos and work-flow need to more closely mirror our Tails git repo and work flow, e.g. each have the following branches: experimental: *all* features and bugfixes up for review should be merged into it, and the snapshot uploaded to Tails experimental APT suite should be built from this branch. devel: after a review ACK of a new feature or bugfix, it's merged into this branch and a new snapshot is built and uploaded to Tails devel APT suite. Note that all such snapshots will be replaced with a proper release when the RM builds this branch during the release time of the next Tails major release. master (corresponds to Tails' stable): after a review ACK of a new bugfix, it's are merged into this branch and a new snapshot is built and uploaded to Tails stable APT suite. Note that all such snapshots will be replaced with a proper release when the RM builds this branch during the release time of the next Tails point-release. I'm not sure I actually propose that we start following this procedure as it adds a fair bit of overhead, but I at least hope it makes clear the problem as I see it. Or do we think that we can just go on solving these situations in an ad-hoc, case-by-base basis without experiencing major headaches along the way? Thoughts? Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
