New Lift release process wiki page

[David Pollak]

http://wiki.github.com/dpp/liftweb/committer-release-process

Please note the "branch" vs. "tag" change in the process.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Heiko Seeberger]

David,

I do not understand the naming convention "Lift_x_version". Is this something like "Lift_x_2.0" or "Lift_2.0" or ...?

git checkout -b Lift_x_version

Maybe it is possible to find a better symbol, e.g. "Lift_MAJOR.MINOR[.MICRO][-QUALIFIER]" with QUALIFIER something like "M8"? Anyway, could you please write up some examples in the Wiki?

Thanks,

Heiko

2009/12/10 David Pollak <feeder.of...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

[David Pollak]

On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

David,

I do not understand the naming convention "Lift_x_version". Is this something like "Lift_x_2.0" or "Lift_2.0" or ...?

git checkout -b Lift_x_version

Maybe it is possible to find a better symbol, e.g. "Lift_MAJOR.MINOR[.MICRO][-QUALIFIER]" with QUALIFIER something like "M8"? Anyway, could you please write up some examples in the Wiki?

Lift-1.1-M8

You're welcome (encouraged) to update the process.
 

[Heiko Seeberger]

2009/12/10 David Pollak <feeder.of...@gmail.com>

On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

David,

I do not understand the naming convention "Lift_x_version". Is this something like "Lift_x_2.0" or "Lift_2.0" or ...?

git checkout -b Lift_x_version

Maybe it is possible to find a better symbol, e.g. "Lift_MAJOR.MINOR[.MICRO][-QUALIFIER]" with QUALIFIER something like "M8"? Anyway, could you please write up some examples in the Wiki?

Lift-1.1-M8

Ah, OK. Thank you.

 

You're welcome (encouraged) to update the process.

Sure!

Did it:

create a new branch for the release:
Name it Lift-VERSION with VERSION = MAJOR.MINOR[.MICRO][-QUALIFIER], e.g. Lift-2.0-M8 or Lift-2.0.1

git checkout -b Lift-VERSION

Heiko

[Kris Nuttycombe]

Maybe I missed it, but it's probably desirable to tag the actual
release point as well as create a branch, isn't it?

Kris

[David Pollak]

On Thu, Dec 10, 2009 at 3:45 PM, Kris Nuttycombe <kris.nu...@gmail.com> wrote:

Maybe I missed it, but it's probably desirable to tag the actual
release point as well as create a branch, isn't it?

In Git, it's the same thing.  The creation of the branch is a marker at a particular commit... the same as a tag.

The advantage is that you don't have the step of setting all the pom.xml files from M8 back to SNAPSHOT
 

[Kris Nuttycombe]

Right, but the moment another commit goes on the branch you no longer can see exactly where the release was cut from. Thus it's best to both branch and tag. In git a branch is a mutable reference to a commit whereas a tag is immutable. That way you can do bugfixes on the release branch and diff against the tag to see what has changed, and regularly merge down to master.

On Dec 10, 2009 4:51 PM, "David Pollak" <feeder.of...@gmail.com> wrote:

On Thu, Dec 10, 2009 at 3:45 PM, Kris Nuttycombe <kris.nu...@gmail.com> wrote: > > Maybe I miss...

In Git, it's the same thing.  The creation of the branch is a marker at a particular commit... the same as a tag.

The advantage is that you don't have the step of setting all the pom.xml files from M8 back to SNAPSHOT
 

> > > Kris > > On Thu, Dec 10, 2009 at 7:47 AM, Heiko Seeberger > <heiko.s...@googlemail.com> ...

-- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress....

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lif...@googlegroups.com. To unsubscribe from this group, send...

[David Pollak]

On Thu, Dec 10, 2009 at 8:18 PM, Kris Nuttycombe <kris.nu...@gmail.com> wrote:

Right, but the moment another commit goes on the branch you no longer can see exactly where the release was cut from. Thus it's best to both branch and tag. In git a branch is a mutable reference to a commit whereas a tag is immutable. That way you can do bugfixes on the release branch and diff against the tag to see what has changed, and regularly merge down to master.

Fair enough.  Please update the wiki to reflect a branch and then a tag of the branch after the pom.xml stuff is committed.

On Dec 10, 2009 4:51 PM, "David Pollak" <feeder.of...@gmail.com> wrote:

On Thu, Dec 10, 2009 at 3:45 PM, Kris Nuttycombe <kris.nu...@gmail.com> wrote: > > Maybe I miss...

In Git, it's the same thing.  The creation of the branch is a marker at a particular commit... the same as a tag.

The advantage is that you don't have the step of setting all the pom.xml files from M8 back to SNAPSHOT
 

> > > Kris > > On Thu, Dec 10, 2009 at 7:47 AM, Heiko Seeberger > <heiko.s...@googlemail.com> ...

-- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress....

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lif...@googlegroups.com. To unsubscribe from this group, send...

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

[Indrajit Raychaudhuri]

On 11/12/09 9:48 AM, Kris Nuttycombe wrote:
> Right, but the moment another commit goes on the branch you no longer
> can see exactly where the release was cut from. Thus it's best to both
> branch and tag. In git a branch is a mutable reference to a commit
> whereas a tag is immutable. That way you can do bugfixes on the release
> branch and diff against the tag to see what has changed, and regularly
> merge down to master.

+1

However, David has a valid point. We can let this M8 proceed the way
it's going and take this up for subsequent releases.

With some luck we can let maven-release-plugin handle some of these for
us automatically too.

>
>> On Dec 10, 2009 4:51 PM, "David Pollak" <feeder.of...@gmail.com

>> <mailto:feeder.of...@gmail.com>> wrote:
>>
>>
>>
>> On Thu, Dec 10, 2009 at 3:45 PM, Kris Nuttycombe
>> <kris.nu...@gmail.com <mailto:kris.nu...@gmail.com>> wrote:
>> > > Maybe I miss...
>>
>>
>> In Git, it's the same thing. The creation of the branch is a marker
>> at a particular commit... the same as a tag.
>>
>> The advantage is that you don't have the step of setting all the
>> pom.xml files from M8 back to SNAPSHOT
>>
>> > > > Kris > > On Thu, Dec 10, 2009 at 7:47 AM, Heiko Seeberger >
>> <heiko.s...@googlemail.com

>> <mailto:heiko.s...@googlemail.com>> ...

>>
>>
>>
>> -- Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress....
>>
>> You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>>
>> To post to this group, send email to lif...@googlegroups.com

>> <mailto:lif...@googlegroups.com>. To unsubscribe from this group, send...
>>
> --

>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.

[Kris Nuttycombe]

On Thu, Dec 10, 2009 at 9:26 PM, Indrajit Raychaudhuri
<indr...@gmail.com> wrote:
>
>
> On 11/12/09 9:48 AM, Kris Nuttycombe wrote:
>> Right, but the moment another commit goes on the branch you no longer
>> can see exactly where the release was cut from. Thus it's best to both
>> branch and tag. In git a branch is a mutable reference to a commit
>> whereas a tag is immutable. That way you can do bugfixes on the release
>> branch and diff against the tag to see what has changed, and regularly
>> merge down to master.
>
> +1
>
> However, David has a valid point. We can let this M8 proceed the way
> it's going and take this up for subsequent releases.
>
> With some luck we can let maven-release-plugin handle some of these for
> us automatically too.

It's also not a big deal to correctly tag the release commit after the
fact, so we can do that whenever.

I've yet to get maven-release-plugin working properly with git, but
it's been a year or more since i've spent much time on it so perhaps
things have improved since then.

In any case, I've added the tagging step to the wiki after the
verification that the release has proceeded correctly.

Kris

[Charles F. Munat]

Nice

[Indrajit Raychaudhuri]

On 11/12/09 11:25 AM, Kris Nuttycombe wrote:
> On Thu, Dec 10, 2009 at 9:26 PM, Indrajit Raychaudhuri
> <indr...@gmail.com> wrote:
>>
>>
>> On 11/12/09 9:48 AM, Kris Nuttycombe wrote:
>>> Right, but the moment another commit goes on the branch you no longer
>>> can see exactly where the release was cut from. Thus it's best to both
>>> branch and tag. In git a branch is a mutable reference to a commit
>>> whereas a tag is immutable. That way you can do bugfixes on the release
>>> branch and diff against the tag to see what has changed, and regularly
>>> merge down to master.
>>
>> +1
>>
>> However, David has a valid point. We can let this M8 proceed the way
>> it's going and take this up for subsequent releases.
>>
>> With some luck we can let maven-release-plugin handle some of these for
>> us automatically too.
>
> It's also not a big deal to correctly tag the release commit after the
> fact, so we can do that whenever.

Of course.

>
> I've yet to get maven-release-plugin working properly with git, but
> it's been a year or more since i've spent much time on it so perhaps
> things have improved since then.

Indeed. This is a what my 'with some luck' implied :) However,
maven-release-plugin relies on Maven SCM and there has been some
displacement toward better git support in Maven SCM. This makes me
hopeful. If it works, it can also help us automate some of the actions
during H-0.

I think maven-scala-plugin uses this with some success. DavidB/Josh can
comment on this.

I intend to experiment on this and put some of them into effect with the
2.0 structure. Depending on success level, we can tweak the wiki later.

>
> In any case, I've added the tagging step to the wiki after the
> verification that the release has proceeded correctly.

Perfect.

>
> Kris