Sean, As far as delineating major versions, I'll leave that to you to wrestle with the core team. But I'd say, If there's no need to break things up right now into major versions, don't. Leaving yourself a way out to manage branches in the future is what I'm proposing. Using a single value just makes that tough and creates strange race conditions if you don't figure it out early.
My 2ยข? I think you're mostly targeting support for Chrome in 0.1, you might want to add support for both Chrome/Firefox, that seems to be a logical place for a more major revision, say a 0.2. That way if there's some set of users that are using 0.1.x branches, but you found that to support FF in 0.2.x that forces a major api change, you can safely make that change and not effect 0.1.x users. You can choose to stop support for some old branch, but you're agreeing not to change the underlying API to 0.1.x. But say some security flaw is found in code that effects both 0.1.x and 0.2.x, you'd want to patch both, but not force all users to upgrade to 0.2.x. So take the versioning approach more as a mechanism for defining a roadmap. You've started some of that here graphically: http://openpgpjs.github.com/ Maybe: Define v 1.0 as where you want a full set of features to be for JS and Chrome, until you get there it's a 0.x.x version, bug fixes and maint. would be 1.x.x. Define v 2.x, 3.x as supporting more engines/formats as you want. You can always revise the future goal before you start. All this will make you think about what are the full compliment of features you need for each version, which is a good thing. Also if you define the roadmap of things to get done, on an open source project, you're likely to get more contributors to step up and say, I need that feature, so I build it and contribute it back. It also allows someone from the community to start building the future out before you start... say someone need's IE support, but it's not slated to start until v 4.x... that can live in that branch for an indeterminate amount of time until you decide to actually deal with it, but you have the code somewhere where it doesn't effect current versions in production. Jim Klo Senior Software Engineer Center for Software Engineering SRI International t. @nsomnac On Jul 30, 2012, at 6:19 PM, Sean Colyer wrote: I stupidly was not paying attention during part of my changes and was in a detached HEAD state and merged the pull request back in. Once I realized this, I reverted master back to the change it was at. I've opened a new pull request that people can look at https://github.com/openpgpjs/openpgpjs/pull/50 that includes the additional commit I was originally just going to fold into master that is a bugfix for: https://github.com/seancolyer/gmail-crypt/issues/12 Jim -- I think that's a reasonable approach. Do we have any suggestions on how we might delineate what are deemed to be major versions? So far we've pretty much dodged versioning all together. Sean On Mon, Jul 30, 2012 at 9:00 PM, Jim Klo <[email protected]<mailto:[email protected]>> wrote: The problem introduced however is that you cannot delineate between versions between significant changes in design.. say you have to patch all released versions with security fix (say you have a 0.1, 0.2, and 0.3)... by using only a datestamp you don't know which architectural fork the code base belongs from version number alone. I might suggest following a pattern that Node, Python, and several others follow where you use: major.minor.rev where OpenPGP.js v0.1.20120730 This way you can have several versioned 'forks' and can easily distinguish, ie: v0.2.20120730 from v0.1.20120730 - Jim Jim Klo Senior Software Engineer Center for Software Engineering SRI International t. @nsomnac On Jul 30, 2012, at 5:17 PM, Sean Colyer wrote: I've made a pull request to change the way we do versioning for our builds. Basically replacing the hardcoded "OpenPGP.js v0.1" with a date like "OpenPGP.js 20120730". I'm interested to see if others think this is a good idea, the project has changed hugely since the original "0.1" and I think it makes a lot more sense for us to have the version reflect which version of code is actually running. However, please let me know if this doesn't seem like a good approach? https://github.com/openpgpjs/openpgpjs/pull/49 Sean _______________________________________________ http://openpgpjs.org<http://openpgpjs.org/> _______________________________________________ http://openpgpjs.org<http://openpgpjs.org/> _______________________________________________ http://openpgpjs.org
_______________________________________________ http://openpgpjs.org
