search

jbake-org / jbake

Java based open source static site/blog generator for developers & designers.
http://jbake.org
MIT License
1.12k stars 326 forks source link

More Frequent Release Cycles? #374

Open manikmagar opened 7 years ago

manikmagar commented 7 years ago

JBake is making awesome progress :+1: and thanks to @jonbullock, along with all the contributors for keeping it active and alive.

Many releases are have happened and numerous will come along. I feel that probably we should have more frequent release cycles.

Bug fixes: Patch change Bug fixes should be released as soon as possible with increment in patch level, without waiting for other enhancements.

Enhancements: Minor Version change May be less number of enhancements can be bundled in every minor release, and so releasing new features more frequently. Implemented, tested and verified enhancements can get more push for the release.

Again, it may be just me because I can't wait long for the new features in pipeline :). And, I can also help wherever needed :)

Regards, Manik

jonbullock commented 7 years ago

Thank you for all of your contributions @manikmagar JBake wouldn't be where it is today without contributions like yours from the community.

I would love to make releases more frequent and I'm acutely aware that I'm the bottle neck - I have some ideas on how this can be improved though and the recent switch to Gradle should help with this. Keeping the scope of a release static is also a problem and I'm very much guilty of allowing scope creep.

I have been trying to keep to semvar for versioning although I haven't got many bug fixes releases out unfortunately. My plan moving forward is to review what is left open for 2.6.0 and push back any big changes/enhancements that haven't been started or close to being finished to 2.7.0.

Thanks for the offer of help too, I may assign a one or two issues to you during my review for 2.6.0.

manikmagar commented 7 years ago

Sure @jonbullock, I would love to help.

May be, we can add a urgency vote on the open issues. If more people vote for anything, we can move it up in the queue.

ancho commented 7 years ago

Good Idea. How about using github projects to visualize and plan work? Combined with a vote this could be nice to see who is working on a feature or which one is free to pick etc...

jonbullock commented 7 years ago

Yeah sure I'll start off by creating a project for the 2.6.0 release.

How would voting work on issues?

manikmagar commented 7 years ago

Voting could be as simple as, adding 👍 / 👎 reaction to the issue ... like the one to this issue itself.

jonbullock commented 7 years ago

Ahh I thought I'd missed a new GitHub feature 😄

Yeah sounds good to me - how should we encourage this behaviour ... README, contributing guide?

manikmagar commented 7 years ago

We can add it to Contribution guide. We can also look at using Github issues template to add a footer to each issue about the voting message.

ancho commented 7 years ago

@jonbullock Is it possible that assigned users are able to move the issues around? I'm not able to change the state to In Progress.

jonbullock commented 7 years ago

Can you try it again now?

ancho commented 7 years ago

Works for me. Thank you.

I wonder if it is possible to move a project from a repository to the organization? Because a release project like this one touches more than one project. There are tasks for the website project to add some documentation or changes to be made on the gradle or maven plugin.

Maybe for the next time.

jonbullock commented 7 years ago

Excellent. I'll have a look at that now... I thought projects were repo specific but you can create them at the org level.

jonbullock commented 7 years ago

I can't see anything to move a project but I've put a request into GitHub to see if they can.

It's not a huge problem to re-create it if need be.

jonbullock commented 7 years ago

It's been moved, can you double check you can still move issues around?

ancho commented 7 years ago

still works ;)

manikmagar commented 7 years ago

Ok, question about the tasks in project. Should I be moving task to 'Done' when I am done working on it or after it is merged to master? Many of the 2.6.0 tasks are implemented and ready to me merged but they were still under In Progress, I just moved them to Done (they are not merged yet).

ancho commented 7 years ago

My interpretation of the three stages.

We could add more columns to reflect another workflow. But I like to keep it as simple as possible.

manikmagar commented 7 years ago

Let's keep it simple. Todo and In Progress are good.

'a pull request is accepted and ready to merge' - I assume this means, PR is submitted, reviewed by someone to say, yes, it is ready for merge. Should this be a formal review request?

manikmagar commented 7 years ago

One more thought I am having is, is it possible to release SNAPSHOT versions with ready-to-merge items from planned release? This might allow others to use latest features/bugfixes before they are released, good for testing :)

ancho commented 7 years ago

No. Yes. I don't know..what do you mean by formal?

But basically yes. The workflow I have in mind is similar like you said.

  1. Someone opens a PR.
  2. A member picks the PR for a review and drop it to the In Progress column.
  3. The PR is considered acceptable. (maybe a short comment why?)
  4. drop issue to done
ancho commented 7 years ago

Jep. Seems so https://www.jfrog.com/confluence/display/RTF/Deploying+Snapshots+to+oss.jfrog.org

manikmagar commented 7 years ago

On PR, you can request review to someone, by Formal, I meant using that.

jonbullock commented 7 years ago

I had been keeping the PR's ready to be merged in the In Progress state but that was just my initial mapping of work to those default states. @ancho mapping for PR's makes more sense as the work is to review/suggest changes. Not used the review system on GitHub myself yet so open to suggestions on how that can be used....