Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semver 1.0 release #1059

Closed
martinheidegger opened this issue Feb 18, 2018 · 11 comments · Fixed by #1060
Closed

Semver 1.0 release #1059

martinheidegger opened this issue Feb 18, 2018 · 11 comments · Fixed by #1060

Comments

@martinheidegger
Copy link

I noticed that marked starts fresh in this year. However this release broke a dependent. Noticing that is 0.3.14, I wonder if it would be in the spirit of "starting fresh" and go for the 1.0 release and in that sense start following semver (breaking change: semver: major)?

@UziTech
Copy link
Member

UziTech commented Feb 18, 2018

Which dependent did v0.3.14 break? There should not have been any breaking changes.

We have a few milestones we want to get done before a 1.0 release

@martinheidegger
Copy link
Author

firede/msee#58

@joshbruce
Copy link
Member

@UziTech: Possibly something else we didn’t account for (and not sure we could have really) is that dependents of Marked need to point to the new house and publish an update??

Mine is with SimpleMDE...I will submit a PR there to help them out...??

@joshbruce
Copy link
Member

Possibly related to #1058 ??

@Feder1co5oave
Copy link
Contributor

Feder1co5oave commented Feb 19, 2018

No, that in unrelated. It is unclear to me what firede/msee#58 is about, but is seems they were relying on some broken behavior to do something?

@UziTech
Copy link
Member

UziTech commented Feb 19, 2018

Looks like the breaking change was changing the capturing parentheses on code in #1013

firede/msee#59

@joshbruce
Copy link
Member

Sorry, just woke up. NPM doesn't include the vendor name like some other package managers; so, changing the user should have changed anything either.

@UziTech
Copy link
Member

UziTech commented Feb 19, 2018

I submitted a pull request #1060 that would revert the breaking change yet keep the fix in #1013. @joshbruce we probably want to push a patch release in case this affects anyone else.

@martinheidegger
Copy link
Author

While it is commendable that this is fixed - an 1.0 release would be still awesome. I did find your roadmap to 1.0 nice. But it would make me sleep better if the first major was out.

@UziTech
Copy link
Member

UziTech commented Feb 19, 2018

@martinheidegger I agree but we have a ways to go before 1.0. Once this is completely stable (with automated testing, and making it easier to extend without rewriting the parser) we will get a 1.0 release out. But bringing a project back from the graveyard takes a while.

@joshbruce
Copy link
Member

@martinheidegger: The first "stable" will probably be considered the 0.4.0 release, as it will be the release prior to architecture changes that will introduce breaking things, should have the specs covered, and all the options still in place.

0.4.0 will probably see some deprecation of options as well as the major architecture changes.
0.5.0 should make it easier for people add whatever options they want to - as @UziTech mentioned.

Just published the 0.3.15 release - let us know if you find something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants