THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Some
...
notes
...
on
...
how
...
Roller
...
releases
...
are
...
orchestrated.
...
The
...
Release
...
Cycle
...
Following
...
the
...
philosophy
...
of
...
release
...
early
...
and
...
release
...
often,
...
Roller
...
aims
...
for
...
monthly
...
releases.
...
New
...
releases
...
will
...
generally
...
be
...
scheduled
...
for
...
once
...
per
...
month
...
around
...
the
...
beginning
...
of
...
the
...
month.
...
This
...
is
...
flexible
...
and
...
if
...
the
...
team
...
feels
...
a
...
given
...
month
...
does
...
not
...
warrant
...
a
...
new
...
release
...
then
...
we
...
will
...
wait
...
until
...
the
...
following
...
month.
...
Contributing
...
to
...
a
...
release
...
If
...
you
...
want
...
to
...
add
...
a
...
feature
...
to
...
a
...
release,
...
you
...
should
...
create
...
a
...
JIRA
...
issue
...
describing
...
the
...
feature,
...
assign
...
it
...
to
...
yourself,
...
and
...
set
...
the
...
"fix-for"
...
field
...
for
...
the
...
release
...
you
...
want.
...
(see
...
the
...
roadmap
...
view
...
in
...
JIRA).
...
For
...
all
...
but
...
the
...
smallest
...
improvements
...
and
...
bug
...
fixes,
...
you
...
should
...
also
...
write
...
a
...
proposal
...
and
...
get
...
it
...
reviewed
...
by
...
the
...
community
...
on
...
the
...
development
...
mailing
...
list
...
(see
...
the
...
...
...
...
page).
...
If
...
you
...
are
...
working
...
on
...
a
...
feature
...
marked
...
as
...
IN-PROGRESS
...
in
...
JIRA,
...
then
...
when
...
you
...
are
...
done
...
you
...
should
...
mark
...
it
...
as
...
RESOLVED.
...
Any
...
work
...
that
...
is
...
completed
...
should
...
be
...
properly
...
documented
...
(user
...
guide
...
and/or
...
install
...
guide),
...
change
...
lists
...
should
...
be
...
updated,
...
and
...
if
...
needed
...
database
...
scripts
...
are
...
updated
...
and
...
tested.
...
Typical
...
release
...
schedule
...
Generally
...
the
...
team
...
aims
...
to
...
provide
...
the
...
first
...
release
...
candidate
...
(RC1)
...
for
...
a
...
new
...
release
...
on
...
the
...
second
...
to
...
last
...
Thursday
...
of
...
each
...
month.
...
Beginning
...
at
...
that
...
point
...
testing
...
begins
...
and
...
focuses
...
on
...
those
...
features
...
marked
...
RESOLVED
...
for
...
the
...
given
...
release.
...
We
...
iterate
...
on
...
RCs
...
until
...
the
...
community
...
is
...
satisfied
...
that
...
all
...
tests
...
have
...
passed
...
and
...
there
...
are
...
no
...
more
...
issues
...
which
...
should
...
hold
...
up
...
the
...
release.
...
Then
...
the
...
release
...
goes
...
out,
...
ideally
...
around
...
the
...
beginning
...
of
...
each
...
month.
...
At
...
that
...
point
...
all
...
items
...
which
...
passed
...
testing
...
and
...
are
...
included
...
in
...
the
...
release
...
are
...
marked
...
as
...
CLOSED.
...
Release Numbers and Versions
Roller follows the typical Major.Minor.Patch
...
version
...
numbering
...
convention.
...
Major
...
releases
...
A
...
major
...
release
...
is
...
noted
...
by
...
a
...
change
...
in
...
the
...
major
...
release
...
number
...
(i.e.
...
1.x
...
to
...
2.x).
...
major
...
releases
...
are
...
like
...
any
...
other
...
Roller
...
release
...
except
...
that
...
they
...
are
...
expected
...
to
...
include
...
potential
...
database
...
schema
...
changes
...
and
...
for
...
that
...
reason
...
the
...
upgrade
...
procedure
...
may
...
be
...
longer
...
and
...
more
...
involved.
...
major
...
releases
...
are
...
also
...
expected
...
to
...
contain
...
larger
...
sets
...
of
...
changes
...
and
...
more
...
complex
...
feature
...
additions
...
which
...
were
...
too
...
large
...
to
...
complete
...
in
...
a
...
minor
...
release.
...
Minor
...
releases
...
A
...
minor
...
release
...
is
...
noted
...
by
...
a
...
change
...
in
...
the
...
minor
...
release
...
number
...
(i.e.
...
1.2
...
to
...
1.3).
...
minor
...
releases
...
typically
...
contain
...
smaller
...
changes
...
to
...
the
...
code
...
base
...
and
...
can
...
be
...
easily
...
upgraded.
...
Roller
...
users
...
should
...
feel
...
very
...
comfortable
...
about
...
upgrading
...
their
...
Roller
...
installation
...
with
...
a
...
new
...
minor
...
release.
...
Patch
...
releases
...
(emergency
...
bug
...
fixes)
...
We
...
expect
...
that
...
each
...
release
...
of
...
roller
...
will
...
simply
...
be
...
considered
...
a
...
minor
...
release,
...
however
...
should
...
something
...
unfortunate
...
happen
...
and
...
we
...
must
...
do
...
an
...
emergency
...
bug
...
fix
...
for
...
a
...
given
...
release
...
then
...
we
...
may
...
mark
...
that
...
release
...
with
...
an
...
incremental
...
patch
...
version
...
number
...
(i.e.
...
1.3.1).
...
this
...
is
...
not
...
expected
...
to
...
happen
...
often.
Where Work Gets Done
This section tells you where the right place is for your code and in general how the Roller repository is structured.
Roller Trunk
The roller trunk is the main development repository and will try to always represent the version of the code base currently being developed for the next release. Each new release will be made from the trunk and distributed as appropriate. It is expected that any code commited to the trunk will be in full working order _in time for the next scheduled release_
Roller Dev Branch
The roller dev branch will be a branch representing the next major version of roller. So if the roller trunk currently represents the 1.x code base, then the roller dev branch will be for the 2.x code. This branch is mainly created for cases where a certain feature requires enough effort that it is automatically going to be scheduled just for the next major release. This is also where all work that requires major schema changes should happen.
Custom branches
A custom branch can be created whenever a feature is in development that is not on a certain schedule. this allows the custom branch to worked at whatever pace is desired and when the code is ready it can be applied to whatever branch is most appropriate.
Tags
All tags in the subversion repository are meant to be read-only archives of versions of Roller that went final. If you are ever looking for the code to a specific version of Roller you should look here. In roller svn this is at tags/*
How a release happens
Creating a new release from the trunk
coming soon.
Creating a patch release from an old version
coming soon.
An Example
Let's assume that Roller has just recently released version 2.0 and the code repository is as follows ...
| Code Block |
|---|
h2. Where Work Gets Done This section tells you where the right place is for your code and in general how the Roller repository is structured. h3. Roller Trunk The roller trunk is the main development repository and will try to always represent the version of the code base currently being developed for the next release. Each new release will be made from the trunk and distributed as appropriate. It is expected that any code commited to the trunk will be in full working order __in time for the next scheduled release__ h3. Roller Dev Branch The roller dev branch will be a branch representing the next major version of roller. So if the roller trunk currently represents the 1.x code base, then the roller dev branch will be for the 2.x code. This branch is mainly created for cases where a certain feature requires enough effort that it is automatically going to be scheduled just for the next major release. This is also where all work that requires major schema changes should happen. .h3 Custom branches A custom branch can be created whenever a feature is in development that is not on a certain schedule. this allows the custom branch to worked at whatever pace is desired and when the code is ready it can be applied to whatever branch is most appropriate. h2. Tags All tags in the subversion repository are meant to be read-only archives of versions of Roller that went final. If you are ever looking for the code to a specific version of Roller you should look here. In roller svn this is at tags/* !!How a release happens ! Creating a new release from the trunk coming soon. ! Creating a patch release from an old version coming soon. !!An Example Let's assume that Roller has just recently released version 2.0 and the code repository is as follows ... {{{ branches/roller_1.x (the old 1.x branch currently representing roller 1.3) trunk (the current 2.x branch now representing roller 2.1 in progress) branches/roller_3.x (the upcoming 3.x branch which doesn't have anything new yet) }}} |
Matt
...
has
...
some
...
code
...
he
...
has
...
done
...
to
...
implement
...
Acegi
...
security,
...
but
...
he
...
isn't
...
sure
...
it's
...
going
...
to
...
be
...
ready
...
for
...
the
...
2.1
...
release
...
so
...
he
...
gets
...
a
...
custom
...
branch.
| Code Block |
|---|
{{{ branches/roller_acegi (acegi development work by Matt) }}} |
Dave
...
and
...
Allen
...
finish
...
up
...
the
...
2.1
...
dev
...
work
...
and
...
do
...
a
...
new release
| Code Block |
|---|
release {{{ trunk (now represents 2.2 dev work) }}} |
Somebody
...
finds
...
a
...
horrible
...
bug
...
in
...
1.2
...
(the
...
last
...
1.x
...
release)
...
and
...
decides
...
it's
...
worth
...
taking
...
the
...
time
...
to
...
do
...
a
...
fix
...
and
...
release
...
1.3
...
from
...
that
...
branch.
| Code Block |
|---|
{{{ branches/roller_1.x (now represents potential 1.4 release) }}} |
Matt
...
feels
...
comfortable
...
that
...
the
...
Acegi
...
stuff
...
is
...
ready,
...
so
...
the
...
acegi
...
branch
...
is
...
put
...
into
...
the
...
current
...
trunk
...
so
...
it'll
...
go
...
into
...
the
...
2.2
...
release.
| Code Block |
|---|
{{{ trunk (represents 2.2 dev work, with Matt's acegi code) branches/roller_acegi (removed, no longer necessary) }}} |
Anil
...
has
...
some
...
cool
...
tag
...
related
...
feature
...
to
...
work
...
on,
...
but
...
it
...
requires
...
a
...
db
...
change
...
so
...
he
...
will
...
work
...
from
...
the
...
3.x
...
branch.
...
Meanwhile,
...
Dave,
...
Allen,
...
and
...
Matt
...
finish
...
up
...
the
...
2.2
...
code
...
and
...
do
...
the
...
release.
| Code Block |
|---|
{{{ branches/roller_3.x (anil doing tag work) trunk (now represents 2.3 dev work) }}} |
Anil
...
says
...
his
...
tag
...
stuff
...
will
...
be
...
ready
...
within
...
the
...
month
...
and
...
the
...
team
...
agrees
...
that
...
now
...
is
...
a
...
good
...
time
...
for
...
a
...
major
...
release.
| Code Block |
|---|
{{{ branches/roller_2.x (created from trunk after last 2.2 release, represents potential 2.3 release) trunk (now represents 3.0 release, includes Anil's tag work) branches/roller_4.x (created for new major release work) }}} |