-
Notifications
You must be signed in to change notification settings - Fork 2
Development Process
This page describes the development workflow for MyBatis projects.
The general guideline is to reduce branching and merging as mush as possible. Usually you just have to checkout master, add your changes there and pull them back.
This branch contains the development for the next release. Does not matter if it is going to be a minor or a micro release. Usually mayor releases 3.x -> 4.x happen in a different repository.
Once master contains all the required changes for the next release a version is cut following the Release Process. Be careful and do not add new code when cutting a release is planned.
There is not such thing so far. Only last vesion is maintained.
Use the GitHub Issues to track both bugs and feature requests. Even if the change comes from yourself and not from an end user, open an issue, and describe the change there.
When you commit a change, link it to its issue by adding the issue #number to the commit. Note that Github lets you close issues directly from the comment by adding comments like Fixes #issue, Closes #issue. See the details at https://github.com/blog/831-issues-2-0-the-next-generation.
There should be a Milestone in Github's tracker for each release. The Milestone is used to track the changes list of a version.
There is usually only one open Milestone that corresponds to the next release. When fixing an issue, remember to add it to the Milestone.
Project sites are generated by maven from xdoc sources and deployed to Github project pages. See the details at http://pages.github.com/.
To save space and simplify the documentation tasks, only the docs of the last version are published. If there is something important to change in the docs you can change it and publish the site generated out of current SNAPSHOT directly from master.