I suspect the real issue here is the shared dependency on cordova.js which is, at least for now, a neccessary evil. (Once we move to a light core and plugin all the things this should be way less surface for hurt since plugins will, I'm going to assume/propose, become independently versioned.)
But this does raise some interesting thinking. In a sense we treat our tags like channels are treated in chrome. X.X.XrcX === Beta master === Dev X.X.X === Stable Except tags are static whereas channels are more like branches. Thus the re-tag dance. We could consider moving to more than once long lived branch. (Tho this would not solve cordova.js needing to be tagged.) On Thu, Dec 20, 2012 at 10:07 AM, Michal Mocny <mmo...@chromium.org> wrote: > So there is something to be said about having devs shift focus from dev to > testing during an RC. However, as the team grows, not all of us are really > being responsible for cutting releases. Maybe that means we need to train > the entire team to change current behavior, but that doesn't feel > necessary/scalable. > > With growing external contributions, I would have to say that a code freeze > on trunk doesn't seem to make as much sense. > > -Michal > > > On Thu, Dec 20, 2012 at 9:47 AM, Andrew Grieve <agri...@chromium.org> wrote: > >> I definitely think we'd get more done if we didn't have such a long >> code-freeze. I'm not sure this is the same as what you were suggesting, but >> have a script/tool to branch all of the platforms into an rc branch. Then, >> each platform can fix themselves up a bit and tag their RC. Meanwhile, dev >> can continue to happen on edge. >> >> My main concern with our current approach is just that the code-freeze time >> is super long. >> >> >> On Wed, Dec 19, 2012 at 3:36 PM, Marcel Kinard <cmarc...@gmail.com> wrote: >> >> > One of the things that strikes me here is the difference between calendar >> > time and effort time. (This assumes folks already concurred that the rc >> is >> > ready to release.) Based on my reading of http://wiki.apache.org/** >> > cordova/CuttingReleases >> > <http://wiki.apache.org/cordova/CuttingReleases>there >> isn't a lot of effort time involved to cut a release. It seems like a >> > good chunk of the calendar time is getting folks to tag their platform. >> > Ideally the promotion from rc to final should take very little effort >> time. >> > >> > What I like about the rc is that it provides a settling mechanism for the >> > churn to calm down, run tests across more integration, and see the bigger >> > picture to assess release readiness. I would expect that the promotion >> from >> > edge to rc should take a decent amount of effort time, but not because of >> > the "cut" activities. >> > >> > So when we are at rc and don't find any surprises, why does it take a >> week >> > to promote to final? If we spend a week in rc1, another week in rc2, and >> > another week to cut final, that leaves only 1 week in a 4-week cycle for >> > active dev work? >> > >> > I like the ideal of a channel/stream/branch/whatever where there is a >> > place for the rc to settle without necessarily blocking commits to edge. >> > Where I'm going with this is that if there is an area where commits to >> the >> > rc are carefully controlled, then perhaps one person (i.e, Steve G) could >> > cut the release for ALL platforms using scripts. This may involve that >> one >> > person tagging/branching/whatever across multiple platforms. >> > >> > I also like putting the "how to cut" magic in each platform. Then perhaps >> > a good chunk of coho is tests to make sure that the platform magic >> > delivered the correct format to it. >> > >> > -- Marcel Kinard >> > >>
