search

shonfeder / tokenize

A tokenizer written in (SWI-)Prolog. It has some useful features and some flexibility and it might improve.
The Unlicense
11 stars 5 forks source link

make stable #26

Closed Anniepoo closed 5 years ago

Anniepoo commented 5 years ago

I know there are people depending on tokenize already. I used it in a work project at my old employer.

We should start doing dev vs master (IIRC the package manager kind of hoses you if you update the branch. May be an old bug, but...)

And we should work out how we support current users if we're doing an API redesign.

shonfeder commented 5 years ago

I believe I have the packags set up to only track GitHub releases (see no new updates to the pack despite pushes to master): https://github.com/shonfeder/tokenize/releases

Using github releases, as this does, every release version gives a tag to the commit released, so I don't think we need a release vs. develop branch. But I guess to support people deploying from source, it would be good to have a stable vs. a develop branch.

I'll put that in place and make develop the default branch going forward.

For compatibility, I think we should increment the major version when we release the new changes, and start tracking release notes.

If we release a properly versioned package, I should think it is the responsibility of users to be sure they check for breakage between major version updates. Do you think that's too harsh?

shonfeder commented 5 years ago

Made a develop branch and set that as the default. Will wait to hear feedback re: versioning, support, and compatibility.

shonfeder commented 5 years ago

Additionally, according to semantic versioning (and I think common conventions):

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

So I really don't think we need to worry about this too much. If you know of a party that doesn't specify their version, and their usage might break if we update, good to warn them. But I don't think we need to be previous about API changes until we push a 1.0.

Anniepoo commented 5 years ago

yup, I concur, this was just thinking 'hey, if we keep going on master and majorly change the package, when we release new stuff we break old users.'