Sorry to hijack thread, but speaking of versioning it reminded me. Google has updated Chrome in recent weeks complicating the install of packed extensions. Equally it will soon require manifest v2 conformance - and basically push distribution out via Chrome App Store.
I noticed the Chrome app, which honestly I haven't updated in awhile - but looks like it hasn't changed much looking at GitHub. Anyways, Chrome complains about the extension's version. I've not tried updating it myself to see if it's trivial for OpenPGP.js, but the banning of eval() and Function are probably the biggest offenders, followed by a ban on inline script. - Jim Sent from my iPad On Aug 22, 2012, at 5:43 AM, "Sean Colyer" <[email protected]> wrote: > I did in fact mean using Uint8Array. > > I've merged the changes for major/minor versioning back into the project, I > think this will help us identify what version of the code people are using. I > know that I have run into trouble with this in my extension, and I don't > think it's practical for us to continue manipulate a minor version number for > small changes. > > On a more exciting note, I also did some work with running our code against > jsdoc https://github.com/jsdoc3/jsdoc and have added that into the "doc" > directory. Essentially, it generates Javadoc-style webpages based on our JS > code. We will need to do some work to clean up a lot of our comments, but I > think this provides us with a framework to provide more usable documentation. > > Sean > > On Mon, Aug 20, 2012 at 4:43 AM, Tankred Hase <[email protected]> wrote: > 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 > > > _______________________________________________ > > http://openpgpjs.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ http://openpgpjs.org
