Revision number in manifest vs. hg tag

Development
1

Just noticed these are out of sync: one is 1024, the other 1023. Would be
great if someone could add a new tag to rectify this. Thanks.

2

When working with the codebase, you should always sync to last tagged
revision with* announced public availability *to ensure stability (for ODK
Collect, this is 1023).

Since the default branch of ODK Collect is also the development branch with
potentially destabilizing changes, syncing to the tip can introduce
destabilizing/buggy changes.

Going forward, I am likely to adopt a release naming similar to Fedora
Linux, in which odd release versions (e.g., 1023) are stable, and even ones
are development/test versions. In this case, a special 1024 build was given
out to the user reporting issue 692 to attempt to resolve their issue (as I
have no phone that reproduces it here, I needed them to test a potential
fix). I didn't want the user to have test software installed on a phone and
not know they had it, and this version tag is the only way to know what you
have.

The tips of the various codebases are unstable just prior to a release, so
using the last announced publicly available tag is important. If you look
at the ODK Aggregate release tree, you will see a lot of tip activity for
the pending 1.3 release, including a 1.3.0 release tag, but everything is
still in flux as we squeeze in yet one more change before our official
release. Syncing to the 1.3.0 tag anytime since it was first introduced
would not have given you a clean stable version of the software.

Mitch

··· On Tue, Jan 29, 2013 at 6:15 PM, Thomas Smyth wrote:

Just noticed these are out of sync: one is 1024, the other 1023. Would be
great if someone could add a new tag to rectify this. Thanks.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

3

OK thanks for the explanation. So 1024 should not cause me problems in this
case right? But I get the general principle.

··· On 30 January 2013 13:27, Mitch S wrote:

When working with the codebase, you should always sync to last tagged
revision with* announced public availability *to ensure stability (for
ODK Collect, this is 1023).

Since the default branch of ODK Collect is also the development branch
with potentially destabilizing changes, syncing to the tip can introduce
destabilizing/buggy changes.

Going forward, I am likely to adopt a release naming similar to Fedora
Linux, in which odd release versions (e.g., 1023) are stable, and even ones
are development/test versions. In this case, a special 1024 build was given
out to the user reporting issue 692 to attempt to resolve their issue (as I
have no phone that reproduces it here, I needed them to test a potential
fix). I didn't want the user to have test software installed on a phone and
not know they had it, and this version tag is the only way to know what you
have.

The tips of the various codebases are unstable just prior to a release, so
using the last announced publicly available tag is important. If you look
at the ODK Aggregate release tree, you will see a lot of tip activity for
the pending 1.3 release, including a 1.3.0 release tag, but everything is
still in flux as we squeeze in yet one more change before our official
release. Syncing to the 1.3.0 tag anytime since it was first introduced
would not have given you a clean stable version of the software.

Mitch

On Tue, Jan 29, 2013 at 6:15 PM, Thomas Smyth thomas.smyth@gatech.eduwrote:

Just noticed these are out of sync: one is 1024, the other 1023. Would be
great if someone could add a new tag to rectify this. Thanks.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

Correct.

··· On Wed, Jan 30, 2013 at 11:24 AM, Thomas Smyth wrote:

OK thanks for the explanation. So 1024 should not cause me problems in
this case right? But I get the general principle.

On 30 January 2013 13:27, Mitch S mitchellsundt@gmail.com wrote:

When working with the codebase, you should always sync to last tagged
revision with* announced public availability *to ensure stability (for
ODK Collect, this is 1023).

Since the default branch of ODK Collect is also the development branch
with potentially destabilizing changes, syncing to the tip can introduce
destabilizing/buggy changes.

Going forward, I am likely to adopt a release naming similar to Fedora
Linux, in which odd release versions (e.g., 1023) are stable, and even ones
are development/test versions. In this case, a special 1024 build was given
out to the user reporting issue 692 to attempt to resolve their issue (as I
have no phone that reproduces it here, I needed them to test a potential
fix). I didn't want the user to have test software installed on a phone and
not know they had it, and this version tag is the only way to know what you
have.

The tips of the various codebases are unstable just prior to a release,
so using the last announced publicly available tag is important. If you
look at the ODK Aggregate release tree, you will see a lot of tip activity
for the pending 1.3 release, including a 1.3.0 release tag, but everything
is still in flux as we squeeze in yet one more change before our official
release. Syncing to the 1.3.0 tag anytime since it was first introduced
would not have given you a clean stable version of the software.

Mitch

On Tue, Jan 29, 2013 at 6:15 PM, Thomas Smyth thomas.smyth@gatech.eduwrote:

Just noticed these are out of sync: one is 1024, the other 1023. Would
be great if someone could add a new tag to rectify this. Thanks.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com