Hello folks, This was discussed at the AFS and Kerberos Best Practices Workshop, but we've been remiss in sending it out via e-mail. Apologies for that; all three of the gatekeepers have been insanely busy for a variety of other reasons.
We're about to start the OpenAFS 1.6 release process. There will be at least one more release in the 1.5 series, but we're planning on branching the 1.6 release branch relatively soon and then starting release candidates for broader testing, aiming for a 1.6 release within the next few months. After 1.6, we currently have the following plan. This is definitely open for discussion and is not set in stone, but it's our current intention. Please send feedback (preferrably to openafs-devel, since I believe that's where most of the discussion will be). We have the following major work that we hope we can merge this calendar year: * Windows IFS (the native file system implementation) * rxk5 * Object storage (RxOSD) * Rx UDP performance improvements * PTS authentication name extensions * Extended callbacks The following major work we hope to merge in the first half of 2011: * rxgk with Kerberos v5, X.509, and SCRAM support * Protection of anonymous connections * Protection of the server to client callback connection * Server-coordinated byte-range locking Obviously, we'll accept any other work that is completed and ready to merge as well; those are just the major things that we know are in progress and roughly when they're expected to be done. The combination of ongoing SMB problems with the current Windows client and the substantial improvements offered by the Windows IFS client, as well as community feedback on that client and the current development and testing state of that work, leads us to believe that making a fast 1.8 release after 1.6, merging Windows IFS, is worthwhile. Therefore, post-1.6, our release plan is as follows: 1. Create a 1.7 branch based on 1.6 at the same time that we release 1.6.0. 2. Set up the 1.7 branch as a tracking branch for 1.6. This means that 1.7 will automatically get any commits that are applied to 1.6. 3. Submit the Windows IFS work through Gerrit, and merge it into master and onto the 1.7 branch. We just had a long discussion in Jabber about how best to do this merge, and I don't want to assume any outcome for that discussion yet; we're still figuring out what branches the Gerrit submissions will go to first and how they'll be reviewed. But at the end of this process, we'll have the Windows IFS code in both master and on a 1.7 branch, and the 1.7 branch will be exactly 1.6 + Windows IFS. 4. While this merge is in progress, work will continue on master as normal, possibly including development releases. Develoment releases from master will be a 1.9 series starting with 1.9.0. In other words, we're reserving 1.7 and 1.8 for 1.6 + Windows IFS, but we're not delaying any other work. Other work should be able to continue in parallel in the 1.9 series. 5. Release 1.7.0 from the 1.7 branch for testing when the code is all merged. 6. Further changes to fix problems discovered after 1.7.0 will go into master first and then be pulled up to 1.7 following our normal process. 1.7 will also continue to automatically get merges of all commits put into 1.6. 7. Once 1.7 is tested and determined to be stable, release 1.8 from the 1.7 branch and retire the 1.6 branch, since 1.8 will be exactly 1.6 plus Windows IFS. Our target date for this release is September 2010. 8. Continue development towards 1.10 on master, with 1.9 testing releases as desired. The goal for 1.10 is to incorporate all of the changes in the list above marked "hopefully this calendar year." However, the intention is for 1.10 to be a time-based release. Whatever is merged and ready to be shipped as of December of 2010 is what will be in 1.10. 9. In December 2010, branch master to a 1.10 branch and start doing release candidates. Development will continue on master for a release that, if we merge the features in the second set above, we will be calling 2.0. The intent is for this to also be a time-based release, including whatever is ready to ship as of June of 2011. The initial target date for 2.0 release candidates is June of 2011. This means that for a time we'll have at least three active branches: the 1.6 release branch, the 1.7 branch which is 1.6 plus Windows IFS, and master. There is some feeling that we're also likely to need to maintain the stable 1.4 branch a while into the life span of 1.6 and possibly make a few more 1.4 releases even after 1.6.0 is out, at least for UNIX (the 1.4 branch is already not recommended for Windows). Someone else should speak to Mac OS X from the 1.4 branch. However, the fewer branches we have, the less work there is, so of course we'd like to reduce the number of maintained branches as soon as we can. Discussion? Comments? Feedback? Once we've revised and firmed up this plan, we'll send something to openafs-announce. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
