coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

For those that weren't on the conference call this morning, let me give some background.

We're getting to the point where powers that be here at Microsoft are wondering how things like nuget and chocolatey fit into our idea of package management, and why we can't just use that stuff.  They would like us all to play together in some sort of unified world where we don't duplicate functionality between pkg managers.

Well, having thought about it a bunch, I think maybe with some moderate directional changes, we *can* align ourselves-still accomplish our goals-without sacrificing anything we are aiming for, as well as preserving the 'CoApp' brand.

I've spent the entire day trying to figure out what we can use, how we can play nice, what we give away and what we keep.

I think we actually came up with a plan that

-          gets developers working with our shallow-forked libraries quickly (and actually should significantly increase uptake of our library packages!) - even to the point that libraries that are suitable for consumption by Win8 (Metro) devs can be supported (not really possible in our old model).

-          lets Nuget control as much around the developer library handling as possible (which is where it really belongs)-essentially making nuget support library packages for native code.

-          shares as much code between nuget and CoApp as possible (with CoApp using Nuget as a component)

-          elegantly supports IAAS, PAAS, Server,Desktop, developers, embedded, offline, and Drawbridge in a single model. Maybe even WP8.

-          supports stuff like 'chocolatey' without sacrificing security and trustworthiness elsewhere. (and not 'becoming' chocolatey either...)

-          still should support all of the priorities that we have cared about  (including frictionless install ,etc)

-          maintains 100% of our shallow for effort as still useful

-          provides a lightweight WMI centralized component and plugin architecture to tie (anyone who wants to play nice[ie, Windows CBS, Ruby, Python, Perl, Node, etc...]) together (good for internal and external)

and a bunch more....

I think it may actually be easier to do some things than we had been thinking about before.  Certainly, we'll be able to deliver some very useful functionality pretty quickly.

I'll be documenting this and sharing it with you next week...

G