I agree that this is the most important thing in keeping the project moving forward. I added a Roadmap page to the wiki https://github.com/openpgpjs/openpgpjs/wiki/Roadmap I'd like others to take a look/comment/edit.
I'd like to avoid this becoming a duplicate of our issues page but have a handful of large things that we can tackle. In my opinion, I think top priority things will be to - Documentation - Flush out existing issues dealing with some more packets/clients that we don't currently - Firefox support I think some of the other things like significant refactoring will be a stepping stone to things like UTF-8 better file support. Thoughts? Sean On Mon, Jul 30, 2012 at 9:48 PM, Jim Klo <[email protected]> wrote: > 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]> 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
