-
Notifications
You must be signed in to change notification settings - Fork 2
Development Process
This page describes the development workflow for MyBatis projects.
Style is free. Each project may use its own style. So when adding code to a project, follow its style to keep the style consistent.
To avoid copyright problems make sure that all artifacts hold this header:
/*
* Copyright [year] the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
In case you are merging contributed code make sure that the header is present on all artifacts. If if is not, ask the author to add them before merging the code. Do not accept any contribution without the ASL.
Using the @autor javadoc tag is OK.
Have a look at http://semver.org/spec/v2.0.0.html
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.
If you want to code an experiment or draft a new feature for discussion, fork the repo to your personal Github account and perform the changes there. Merge them back to the official repo by sending a Pull Request.
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 changing code, add a comment to point to the issue that exaplains the change.
When committing 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, etc. 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.
When a new release is cut, close the corresponding Milestone.
User Github releases to tell users about the releases.
For each release:
- Add a link to its milestone so you can easily see the changes included in the release
- Add a release note telling the purpose of the release and anything you think that the users must know.
For every release you perform, add an annoucment to www.mybatis.org in Blogger.
The annoucement usually contains the same information as the Github release:
- A link to the closed Milestone
- The release notes
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.
Site publishing is executed by executing mvn site-deploy.