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

update release page to include history of the releases and binaries #14

Closed
GitMensch opened this issue Apr 5, 2018 · 5 comments
Closed
Assignees

Comments

@GitMensch
Copy link
Collaborator

It is simply nice to have the history shown in the release page to know what changed - for an example see https://github.com/Bill-Gray/PDCurses/releases (if you want me to I'm fine to do the same here, but this would need rights on this project).
As you release the binaries on SF already it would be also nice to have the binaries here next to the sources in the release (if you are fine with this and assign rights [could be temporary, too] I'd do it to polish the release page).

@lexxmark
Copy link
Owner

lexxmark commented Apr 5, 2018

Your help is very appreciated.
Honestly I have no time to do it in nearest weeks.
I have added you to the project collaborators, is that sufficient?

@GitMensch
Copy link
Collaborator Author

Yes, it is enough. I'll start with polishing the releases soon.

The other items need more thoughts put in first.
Especially:

  • Do we need to have the bin directory under version control (especially when we have the binaries in the releases, soon)?
  • Do we need to keep the two branches? I think moving the 2.x bison in to the main branch (adding a "new" VS/CMake entry and splitting chocolately into two directories) would be useful (there are actually minor differences in non-bison parts between those branches and it looks like you've did the changes in both (without merging the changes from master to branch).

What do you think about these two issues?

@lexxmark
Copy link
Owner

lexxmark commented Apr 6, 2018

I agree. Just some notes:

  1. bin folder includes non binary stuff. May be we should move it to src/ subfolders and copy to output dir during building? So output dir will have executables and all needed stuff.
  2. I usually cherry-pick commits from master to bison2.7 I hope further upgrades m4 code won't break frozen bison2.7 code.

@GitMensch GitMensch self-assigned this Apr 6, 2018
@GitMensch
Copy link
Collaborator Author

Releases considered to be finished:

  • tags for all old releases I could fine code for (some are missing, I assumed the code was just locally) --> from 9 to 25
  • release notes added / adjusted for all 25 releases, taken from SF README.txt + references to release notes for bison/flex when updated
  • binary packages added to all releases (downloaded from https://sourceforge.net/projects/winflexbison/files/old_versions/)
  • included bison/flex version in tag title (only done on the first two pages of releases)

I hope you like the result. Obviously this is only useful if releases-to-come (flex 2.6.5 is on its way) use a similar publishing.

I'll add the PDF for integrating the build rules as soon as this is done (but this is tracked with #15).

@lexxmark
Copy link
Owner

lexxmark commented Apr 8, 2018

Thank you for a great work

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

No branches or pull requests

2 participants