Closed mirisuzanne closed 3 years ago
I don't think you are getting ahead of anything here. I agree, we should put version numbers on things... and use tagged GitHub releases. I do think offering it via NPM or whatever package manager is a good idea — to the extent we keep it all fairly simple for us. And useful to developers, without getting all edge-case-y.
I do think it's possible we might end up with a website that has a few options for downloading it (maybe not... and I don't want to over engineer that part from the start)... but since that's where so many other similar projects end up (see any starter kit with it's "custom build tool" on it's website).... so I don't want us to set ourselves up now to be in a bad place later.
@callahad and I had some conversations about a while back. I think he reserved us a namespace on a package manager system, in fact. Maybe he wants to chime in here. Dan?
As for the specifics:
Tagged Github releases using semver would be a good first step, without any additional tooling.
I agree.
From there, we might want to consider: Add a changelog.md to track release notes?
Good idea.
Add a package.json and publishing to npm?
Yup.
For anyone using via copy/download (no package manager), is it useful to have a version number in comments at the top of each file?
I lean towards no... but... hm.... I'd love to hear from people. Maybe yes?
For anyone using via copy/download (no package manager), is it useful to have a version number in comments at the top of each file?
I'm mainly just lurking here, but can chime in to say that for me this would come in handy. At my company we often store polyfills and resets as static files in the context of the main CMS that we use, so a little note with version info is useful for us. Often we add such notes ourselves but it's not standardized.
If we do add version numbers in the files, we'll just want to make sure the release process is well documented - because they otherwise become easily outdated.
Something like KSS (or similar) might help us maintain organized/meaningful comments, and get a small documentation site auto-generated at the same time. I'll look into some options.
I think he reserved us a namespace on a package manager system, in fact. Maybe he wants to chime in here. Dan?
Turns out NPM strongly discourages reserving names before use, so we'll have to cross that bridge when we get to it. But NPM has pretty favorable policies around naming disputes which would cover the most likely scenarios for us.
Or we could publish what we have right now just to get out there, if y'all think it's ready enough.
@callahad I'm going to try and get a v0.1.0 release packaged up by the end of the week so we can move forward on that.
Excellent! Let me know if you need anything from my end on that. :)
On Wed, Sep 11, 2019, 17:05 Miriam Suzanne notifications@github.com wrote:
@callahad https://github.com/callahad I'm going to try and get a v0.1.0 release packaged up by the end of the week so we can move forward on that.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozdevs/cssremedy/issues/53?email_source=notifications&email_token=AAAF5AJFF7AFET3EPWIGKHDQJEJLXA5CNFSM4IUOCXWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6PAJVQ#issuecomment-530449622, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAF5AJGF6IAWW6XWLKOMITQJEJLXANCNFSM4IUOCXWA .
@callahad not sure if you saw that we have a beta released here, and ready for release on npm. Not ready enough to make announcements, but ready enough to claim our space. :) I assume you'll want to do that, but let me know if I should get it started.
Sure, I can get that going shortly
On Sat, Sep 14, 2019, 17:27 Miriam Suzanne notifications@github.com wrote:
@callahad https://github.com/callahad not sure if you saw that we have a beta released here, and ready for release on npm. Not ready enough to make announcements, but ready enough to claim our space. :) I assume you'll want to do that, but let me know if I should get it started.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozdevs/cssremedy/issues/53?email_source=notifications&email_token=AAAF5AL2RYRCRUMD6LOZWU3QJUGHDA5CNFSM4IUOCXWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6W7DKY#issuecomment-531493291, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAF5AJPALXGYC4OZVWENG3QJUGHDANCNFSM4IUOCXWA .
Published v0.1.0-beta.1 at https://www.npmjs.com/package/cssremedy, invited Miriam as a co-maintainer. I've set up NPM to require 2FA for all changes or updates to the package; we can relax that if it becomes too much of a burden, but I figure we'll be in there rarely enough that it shouldn't be onerous.
Looks like some common packages (bootstrap, normalize, etc.) set a non-standard style
attribute in their package.json
pointing to the package's main CSS file, but not many tools seem to actually use it aside from postcss-import. Webpack might also support it, but it's unclear. If so, we should definitely add that to our package metadata.
Goals:
We haven't "released" anything yet, but I just want to think ahead about what a release might look like…
Proposal
Tagged Github releases using semver would be a good first step, without any additional tooling. From there, we might want to consider:
changelog.md
to track release notes?package.json
and publishing to npm?Am I getting ahead of things here? Do others feel like it would be useful to have versioning and package management available? I think we should be able to do it in a way that doesn't add any complexity to the plain-css download/copy option.