cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luoq <l...@polyvi.com>
Subject Re: Releasing Platforms Independently
Date Fri, 14 Mar 2014 06:27:49 GMT
For docs, why don't you guys use yuidoc or jsduck, such js documentation tools, to manage docs?
There is @since to indicate version, and rich builtin tags to use.

Furthermore, inline js documentation is much easier to maintain than a separate md doc, I
believe.

It will be worse that the static markdown docs will get messed and hard to explore when there
are lots of versions someday.

Thanks.


— 
Best Regards,
Qi LUO
Sent with Air

On 14 March, 2014 at 6:03:18, tommy-carlos (tommy@devgeeks.org) wrote:

+1 for docs.  

Pretty big pain point for devs.  

On 14 March 2014 at 7:01:18 am, Brian LeRoux (b@brian.io) wrote:  

I definitely love the idea of making this part of the machine move faster,  
and treating platforms as a dependency of the CLI in theory should not have  
any cross cutting impacts *unless* we decide to change the plugin  
interface. Our CLI version effectively becomes the 'Cordova' version. Docs  
needs an overhaul regardless so I see no issue there.  

How do you guys think we go about tackling this? Should we consider  
starting w/ the Docs since that seems to be the squeakiest wheel?  


On Thu, Mar 13, 2014 at 9:55 AM, Michal Mocny <mmocny@chromium.org> wrote:   

> On Thu, Mar 13, 2014 at 11:38 AM, Andrew Grieve <agrieve@chromium.org  
> >wrote:  
>  
> > I think it would be beneficial if we could release updates to platforms  
> > independent from others. Why?  
> > - Far easier to do one-off platform releases (e.g. quick turn-around on a  
> > security update, quick turn around on iOS is broken on the latest Xcode)  
> > - Platforms can release on their own schedule (big new features will get  
> > released sooner)  
> >  
> >  
> > This doesn't come without bumps though. I'd like to use this thread to  
> > explore the idea and to enumerate what would have to change to get there.  
> >  
> > Here are some things I can think of:  
> >  
> > Cordova-docs:  
> > - We have a version drop-down in the top-right corner.  
> > - I think this would mean getting rid of the version drop down (or  
> rather,  
> > not adding new entries to it).  
> > - Always have people pointed at "edge"  
> > - For things that refer to specific versions, put them inline  
> > - E.g. like we do for upgrade guides  
> > - When a new API is introduced & is documented, we'll have to be better  
> at  
> > annotating what version it showed up in.  
> >  
>  
> Huge +1. This is a bit of an effort, sure, but every single damn time I  
> search for a cordova question I end up on docs for cordova 2.3 or  
> something, the version switcher takes me to home, and manually editing for  
> "edge" doesn't always match urls.  
>  
>  
> >  
> >  
> > Blog posts:  
> > - We currently do one release announcement for all the platforms.  
> > - I think it'll actually be a good thing to have shorter & more focused  
> > release announcements (one post per platform)  
> >  
>  
> I'm fine with this, but I do still think we want some special outlet to be  
> "louder" about larger changes much like we have been with monthly cadence  
> releases.  
>  
>  
> >  
> >  
> > Mobile-spec:  
> > - This is on the way out anyway I think, with moving tests into plugins.  
> > - Even so, not a big deal to not have this strictly versioned.  
>  
>  
> >  
> > cordova-js:  
> > - Platforms will have cordova-js cut at different times.  
> > - I don't think this is a good or a bad thing.  
> > - JS versioning stamped at the top of the file:  
> > - Change to have both platform version as well as JS version available  
> > at runtime.  
> > - JS version will just be a "git describe"  
> >  
> > CLI versioning:  
> > - It won't make sense to version it as CadVer-SemVer anymore  
> > - This essentially kills off the idea of CadVer.  
> > - That scheme wasn't working well anyways since you can't actually  
> depend  
> > on the SemVer part of it in a SemVer way (you can't say  
> > dependency=">x.x.x-0.2")  
> > - CadVer-SemVer, I think, is causing people to not update their tools  
> if  
> > they aren't ready to update their platforms.  
> > - With this change, we should just have CLI be SemVer only.  
> > - If we move platforms to NPM, we wouldn't even need to push CLI  
> updates  
> > with platforms.  
> >  
>  
> This is another huge benefit, I think.  
>  
>  
> >  
> >  
> >  
> > Anything else? Please feel free to add inline here on things I've missed  
> > out, or on things you'd be concerned about changing.  
> >  
>  
> Thanks for going over this. Sounds to me like this is almost entirely  
> upside.  
>  


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message