CDN link on jsdeliver needs version update

[ffd8]

Most appropriate sub-area of p5.js?

• Other - CDN linking to library

🎉 on 1.0!
Looking to link to latest CDN, but found a minor issue with jsdeliver paths:
generic https://cdn.jsdelivr.net/npm/p5 – still points to v0.10.2
manual https://cdn.jsdelivr.net/npm/p5@1.0.0 - looks new, but still says v0.10.2 with today's date in header.

Probably just looking at these links too early – but wanted to share incase those details should have updated automatically.

[limzykenneth]

The generic path for jsdelivr is supposed to link to the latest version, not sure how jsdelivr resolves that (while it is also not the recommended way to use it).

https://cdn.jsdelivr.net/npm/p5@1.0.0 is the link you'll get if you searched for p5 on jsdelivr and it is serving the latest version but the header as you pointed out is not showing the correct version, same as cdnjs. While the version downloaded from the website and from github release is showing the right version number. Not 100% sure what's going on here but may be something do to with the npm publish step.

[ffd8]

Yeah not sure why the generic path isn't updating.. perhaps just takes some time. I also wouldn't link to the generic path (though on the p5 website, that's where the 'download -> cdn' path points to. Mainly just wanted to point out that the header info for @1.0.0 still shows old version.

[limzykenneth]

@lmccart I noticed you might had some difficulties running the release script yesterday? I don't mind having a look at the release step and possibly rewrite it to be easier to use but it depends on what problem you were having.

[lmccart]

hi all, sorry about this. @limzykenneth I did run into problems. I kept getting the error: "working dir must be clean. Please stage and commit your changes." I ended up having to do most of the release by hand, but accidentally published the wrong version to npm. there's no way to replace this file so we'll have to bump to 1.0.1 to do that. @limzykenneth if you want to take a look at the release scripts that would be much appreciated. you might need the npm login, just shoot me an email if you need any info.

[limzykenneth]

I'll try to do a release on my fork on github and namespace on npm so shouldn't need the login. I'll update you if I need something.

[limzykenneth]

@lmccart Did you run the release task as grunt release-p5:major? Because for me if grunt release-it is run it does throw the clean directory error, but not for grunt release-p5.

I think the whole thing can be cleaned up quite a bit but will require some degree of rewrite. At most I'm thinking of replacing release-it with np which can take care of everything related to releasing to npm and github (np has interactive UI that is really easy to use, and it creates automatic github release draft with changelog based on commits since the last tag).

np does not directly handle release to bower, releasing the docs, or preparing the zip package but they can be run with npm hooks and existing grunt tasks after running np.

Speaking of bower, I'm not too familiar with bower but I see that the bower release stuff is on another repo on your account. Is it possible to move just bower.json over here and consolidate the library release on this repo. There's also the question of bower being semi-deprecated, but as long as it isn't fully deprecated, we probably should still release there.

PS. Accidentally created a 1.0.1 tag on github. I'm not sure if it can be removed. Might make things a bit messy for the next release. Sorry.

[lmccart]

@limzykenneth as best I recall, I ran grunt release-p5:1.0.0, following the direction in the contributor docs. but it is possible I got it wrong.

the np plan sounds reasonable. maybe separating these into different tasks triggered by webhooks makes debugging a little easier, instead of one script that can fail at any point.

I think we moved bower out because it was confusing to have a copy of the library in the main repo. if this doesn't seem to be an issue, I'd be ok with moving it back in. maybe it just needs a well-named folder structure.

I deleted the 1.0.1 tag, I think it should be ok now for future releases.

[limzykenneth]

I don't think the release step accepts semver number as argument, so passing 1.0.0 could possibly cause some unknown state to occur.

I may have some time next week to work on using np and such.

For bower, we can also move the repo from your account to the Processing account, just as a step for moving towards the next person who will lead the project. Then we won't need to keep a built library here in this repo as well.

[lmccart]

resolved with ac9fd0a
#4459