Since 0.94 will probably be a long lived version with many releases (thinking about 0.94.2 already),we should back port all changes that: 1. Do not break client/server compatibility (in both directions)
2. Do not break server/server compatibility 3. Do not rely on extensive refactoring that happened only in trunk 4. Are not just cosmetic 5. Do not just represent refactoring without any features added or bugs fixed It includes bug fixes, performance improvements, even new features, etc. But nothing that represents risk without an appropriate benefit. #1 and #2 are hard rules, the rest is obviously subject to interpretation. In terms of UI changes. We probably want to keep mere face lifts out, but include changes that provide extra information (new metrics, etc). We definitely want any integrations tests back ported, unless the supporting changes to non-test code are extensive. TL;DR: Back port unless there is a good reason not to; and use good judgment. :) I'll be looking at most changes that go into 0.94. Also, please do not assume that 0.96 is planned as an unstable release. That is not the case at all. It just might take a while to stabilize. This is just off the top of my head, and as usual just my $0.02. -- Lars ________________________________ From: Enis Söztutar <[email protected]> To: [email protected] Sent: Monday, August 20, 2012 11:16 AM Subject: Porting policy from 0.96+ to 0.94 Hi, Last time we were talking Lars (H.) raised the issue that we might need a stable base while 0.96, and its successors are fully baked in for production use. So, it seems that 0.94 branch releases will be a deployment target for some time at least on some of the organizations for some time. We have been backporting a lot of stuff already from trunk into 0.94, but I want to discuss whether we should establish an "official" policy of what should be backported or not. We will definitely want bug fixes in, but what about new UI stuff, or integration tests, etc. If we can agree on general guidelines at least, it will be then easier to decide on a patch-by-patch basis. What do you guys think? Enis
