QUESTION - Do we publish patterns independently or as part of one big release?

[sturobson]

We will be making use of Lerna to help publish the components of the visual framework to NPM.

One decision that needs making...

Do we allow each component to be published independently?
ie: if we update the buttons we can push the new version of that package up with it's version bump

Or do we publish the component library as a whole(fixed)?
ie: if we update the buttons we push a version bump to all packages.

A part from 'hot fixes', would it be better for our audience to 'schedule' releases (in time) which means a 'publishing as a whole' would work better?

Another idea is we could start with indepentently (as we're in alpha) and move to fixed when the VF is at Beta or live?

[khawkins98]

My thought would be independently, provided there are no breaking changes (or at least some sort of fallback).

So, vf-core:2.0.0 might have vf-button:2.0.12 and vf-tabs:2.0.1.

And then if we wanted to revamp how the tabs work (breaking), it would have to go into vf-core:2.1.0 and vf-tabs:2.1.0.

For the EBI VF we aimed for a new point release 6 months after the last release (so not quite 2 a year).

[khawkins98]

Adding a footnote that this versioning method could (should?) also apply the VF WP theme (vf-wp).

So vf-wp:2.0.10 would expect atleast vf-core:^2.0.0. And the vf-wp for EMBL site would also require vf-embl:^2.0.0.

That's my take, anyways.

[sturobson]

I was talking about this w/ @dbushell yesterday. Unless it's a breaking change (v1.2.3 to v2.0.0) where we are breaking the HTML / class name convention (mainly, but there could be other reasons for the breaking change) ... David was thinking that a link to the CDN of the (versioned) .css file would be a easier / better solution.

(I guess that idea should really be it's own issue within thevf-wp repo)

[khawkins98]

Sounds about right to me. The generic vf-wp theme will be quite general in usage, so it probably makes sense to use the kitchen sink CSS+JS from the CDN.

That also makes it possible to have an admin field of "Want a different look? Link to your VF 2.0.X compatible CSS and JS here."

[dbushell]

That was my thinking for the admin config too.

My plan is to make the theme architecture highly plugin based – for example each sidebar widget as individual WP plugins (e.g. Jobs/news from the content hub).

That would allow more modularity. Plugins can be versioned and updated on their own to match VF changes. They could also tell the admin what assets are needed (or get them from the CDN automatically).

But a single versioned CSS/JS is the way I'd like to start as we figure stuff out.

[sturobson]

@khawkins98 as part of the build process to put the new build the visual framework live - can we add a CHORE (new label needed) to make it spit out the CSS and JS to a CDN somewhere>

[khawkins98]

@dbushell Sounds great. I think that would make the devs at EBI (who are responsible for maintenance) really happy, too.

@khawkins98 Do you mean the kitchen sink CSS/JS, or the individual component CSS/JS? The former is already there at:

• https://dev.assets.emblstatic.net/vf/scripts/scripts.js
• https://dev.assets.emblstatic.net/vf/css/styles.css

@pwalter-ebi Just occurred to me we probably need to do a version number on those, a la:

• https://dev.assets.emblstatic.net/vf/2.0.0/scripts/scripts.js
• https://dev.assets.emblstatic.net/vf/{tag}/scripts/scripts.js

[sturobson]

@khawkins98 @pwalter-ebi would keeping the version in the .css file with cache busting be better as it could/would require less effort for people to upgrade?

https://dev.assets.emblstatic.net/vf/css/styles.css?v=2.0.1

[peter-walter]

Cloudfront ignores all querystring parameters, so this approach will not work.

[dbushell]

Would it be possible to do similar to https://unpkg.com whereby non-versioned URLs redirect to the latest version?

That way anyone developing with VF can effective opt-in to the latest assets without updating anything.

[khawkins98]

Yeah, perhaps the path to happiness: /vf/{assets} = latest tag /vf/2.1/ = latest 2.1.x tag /vf/2.0.5/ specific tag (Sent from my mobile.)

…

On Tue, 13 Nov 2018, 14:44 David Bushell ***@***.*** wrote: Would it be possible to do similar to https://unpkg.com whereby non-versioned URLs redirect to the latest version? That way anyone developing with VF can effective opt-in to the latest assets without updating anything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA4pZFm0_K3f2dk35TflBRFGA-M-h90Oks5uusyzgaJpZM4YZcyB> .

[khawkins98]

I think this has already been addressed in versioning notes elsewhere (patterns have their own version numbers) and is being further addressed in the two referenced issues above.

Closing, please reopen if you think we should.