Hi, The roadmap looks good.
Ive recently tested firefox nightly. Window.crypto.getRandomValues() isnt merged yet. What do you mean by "better file handling" in chrome? Do you mean handling of binary data with Uint8Array typed arrays? Tankred Am 19.08.2012 01:28 schrieb "Sean Colyer" <[email protected]>: > 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 > >
_______________________________________________ http://openpgpjs.org
