Author: mikedd
Date: Wed Nov 14 03:21:37 2012
New Revision: 1409073
URL: http://svn.apache.org/viewvc?rev=1409073&view=rev
Log:
Fix release-management, vetoed release, and quick start pages
Modified:
openjpa/site/trunk/content/quick-start.mdtext
openjpa/site/trunk/content/recovering-from-a-vetoed-release.mdtext
openjpa/site/trunk/content/release-management.mdtext
Modified: openjpa/site/trunk/content/quick-start.mdtext
URL:
http://svn.apache.org/viewvc/openjpa/site/trunk/content/quick-start.mdtext?rev=1409073&r1=1409072&r2=1409073&view=diff
==============================================================================
--- openjpa/site/trunk/content/quick-start.mdtext (original)
+++ openjpa/site/trunk/content/quick-start.mdtext Wed Nov 14 03:21:37 2012
@@ -1,8 +1,9 @@
Title: Quick Start
-{excerpt:hidden=true}Getting Started with OpenJPA{excerpt}
<a name="QuickStart-QuickStartGuide"></a>
-# Quick Start Guide
+
+Quick Start Guide
+=============================
We know it can be hard to find the right help sometimes and search engines
can be overwhelming, so we will try to put the most commonly asked for
@@ -13,6 +14,7 @@ to checkout, before wasting your time se
<a name="QuickStart-RuntimeDependencies"></a>
+
## Runtime Dependencies
To use OpenJPA as a stand-alone Java component or with a lightweight
@@ -43,9 +45,9 @@ The JPA spec requires some type of monit
spec does not define how to implement this monitoring. Some JPA providers
auto-generate new subclasses or proxy objects that front the user's Entity
objects at *runtime*, while others use byte-code weaving technologies to
-enhance the actual Entity class objects at *build time*. OpenJPA supports
+enhance the actual Entity class objects at __build time__. OpenJPA supports
both [enhancement](entity-enhancement.html)
- methods, but strongly suggests only using the *build time* enhancement.
+ methods, but strongly suggests only using the __build time__ enhancement.
The following [Entity Enhancement]
page includes more details on both enhancement types, along with examples
on how to setup *build time* enhancement in ANT, Maven and Eclipse
Modified: openjpa/site/trunk/content/recovering-from-a-vetoed-release.mdtext
URL:
http://svn.apache.org/viewvc/openjpa/site/trunk/content/recovering-from-a-vetoed-release.mdtext?rev=1409073&r1=1409072&r2=1409073&view=diff
==============================================================================
--- openjpa/site/trunk/content/recovering-from-a-vetoed-release.mdtext
(original)
+++ openjpa/site/trunk/content/recovering-from-a-vetoed-release.mdtext Wed Nov
14 03:21:37 2012
@@ -2,24 +2,17 @@ Title: Recovering from a vetoed release
<a
name="Recoveringfromavetoedrelease-Recoveringfromabadreleaseoravetoedrelease"></a>
## Recovering from a bad release or a vetoed release
-Recovering from a bad release actually isn't that difficult. You'll have to
-delete the bad tag in SVN and rollback the version numbers in all of our
-pom.xml files.
+Recovering from a bad release actually isn't that difficult. You'll have to
delete the bad tag in SVN and rollback the version numbers in all of our
pom.xml files.
<a name="Recoveringfromavetoedrelease-Deletethetaginsvn"></a>
### Delete the tag in svn
-{code:none}
-$ svn del https://svn.apache.org/repos/asf/openjpa/tags/1.2.0 -m "Rollback
-release"
-
- h3. Rollback version numbers
- If you have perl installed you can do this in a single command for example
-to rollback from 1.2.1-SNAPSHOT to 1.2.0-SNAPSHOT
- {code:none}
- $ perl -pi -e
-"s;<version>1.2.1-SNAPSHOT</version>;<version>1.2.0-SNAPSHOT</version>;g"
-pom.xml */pom.xml */*/pom.xml
+ $ svn del https://svn.apache.org/repos/asf/openjpa/tags/1.2.0 -m "Rollback
release"
+### Rollback version numbers
+If you have perl installed you can do this in a single command for example to
rollback from 1.2.1-SNAPSHOT to 1.2.0-SNAPSHOT
-If you do not have perl installed you can use a similar tool to edit
-multiple files or edit them all by hand.
+ $ perl -pi -e
"s;<version>1.2.1-SNAPSHOT</version>;<version>1.2.0-SNAPSHOT</version>;g" \
+ pom.xml */pom.xml */*/pom.xml
+
+
+If you do not have perl installed you can use a similar tool to edit multiple
files or edit them all by hand.
Modified: openjpa/site/trunk/content/release-management.mdtext
URL:
http://svn.apache.org/viewvc/openjpa/site/trunk/content/release-management.mdtext?rev=1409073&r1=1409072&r2=1409073&view=diff
==============================================================================
--- openjpa/site/trunk/content/release-management.mdtext (original)
+++ openjpa/site/trunk/content/release-management.mdtext Wed Nov 14 03:21:37
2012
@@ -1,7 +1,6 @@
Title: Release Management
<a name="ReleaseManagement-ReleaseManagement"></a>
# Release Management
-{children:depth=3}
<a name="ReleaseManagement-WhereshouldIputmyfix?"></a>
## Where should I put my fix?
@@ -10,22 +9,14 @@ releases are fair game, but may require
<a name="ReleaseManagement-RegardingReleaseManagers"></a>
## Regarding Release Managers
-Once a formal release of OpenJPA has been approved, a release manager is
-assigned. The release manager is often (but not always) the same developer
-who performed the release. This release manager role is intended to be a
-long term branch maintainer who looks after the stability of a formal
-release.
-
-The release manager(s) is(are) responsible for targeting fixes into a given
-version of OpenJPA.
-* Release managers may indicate this by targeting a JIRA issue for their
-branch or may issue a blanket statement that any fix will be accepted.
-* In general only the release manager(s) should target a JIRA issue for a
-branch which they support.
-** An exception to this rule is if the RM has committed changes for their
-branch and forgot to update the JIRA issue.
-* Fixes should not be committed without RM approval. These changes may be
-reverted by the release manager.
+Once a formal release of OpenJPA has been approved, a release manager is
assigned. The release manager is often (but not always) the same developer who
performed the release. This release manager role is intended to be a long term
branch maintainer who looks after the stability of a formal release.
+
+The release manager(s) is(are) responsible for targeting fixes into a given
version of OpenJPA.
+
+* Release managers may indicate this by targeting a JIRA issue for their
branch or may issue a blanket statement that any fix will be accepted.
+* In general only the release manager(s) should target a JIRA issue for a
branch which they support.
+ * An exception to this rule is if the RM has committed changes for their
branch and forgot to update the JIRA issue.
+* Fixes should not be committed without RM approval. These changes may be
reverted by the release manager.
<a name="ReleaseManagement-Somegeneralguidelinesforreleasemanagers"></a>
### Some general guidelines for release managers
@@ -56,9 +47,7 @@ Release Manager before committing </th><
<a name="ReleaseManagement-ContinuousBuilds"></a>
## Continuous Builds
-We are using the Apache Hudson server for continuous builds of several
-releases. Please checkout the [Automated Builds](automated-builds.html)
- page for more details.
+We are using the Apache Hudson server for continuous builds of several
releases. Please checkout the [Automated Builds](automated-builds.html) page
for more details.
