Issue 133 in metacello: MetacelloBrowser: Abstract test not indicated

> - Rewrite the improvement to use feature Z and integrate it to Project X
> as 0.6

This is what I will do.

> - Thanks her but notifies that your process doesn't have branches so you
> can apply the improvement to the official codebase and she'll have to
> have its patch for herself.

Hey! I did not say that branches are not necessary. They are of course necessary!
Now, in the case of the browser, I will suggest to use the last version of the it and try to reproduce the bug.

> I don't see advantages on your process and as I said before is very
> awkward and not what one see on just every open source project where
> anyone can contribute patches to a (reasonable) old release and if yet
> maintained, applied to it without modifications and to the head of
> development possibly with modifications.

I am not saying that my process should rule the World. Emails are such a bad communication medium.
We have studied software processes for a number of companies over the last few months. The results are on my webpage. Each company has its own process, and often very complicated. This is necessary to have a certification cmmi or iso. The process (code, test, commit) is what many people do.

If you found a bug for Pharo 1.0, will this lead to creating a branch Pharo 1.0.1 ?
Or will you try to see if the last Pharo fixed the bug you already provided?

Now, if the browser has many clients who pay for its maintenance, so many, a branch may be created. This is not the case for now. So far we are only two working on the browser.

The way that I and many people program in a simple agile approach is based on keeping the last version green. And I am sure this is not different from how you and Dale program. We are talking about the way of numbering version.
I am offering my help to fix the situation.

> Now, as an aside, the biggest selling point of git (arguably the most
> used distributed SCM software, replacing subversion everywhere on the
> internet, followed by mercurial and bazaar) is the cheap,
> use-for-every-thing-no-matter-how-small-the-change-to-project-is,
> branching model. And the point of a branch is to allow the developers to
> *use* as many commits as they want to implement some functionality,
> knowing that when merging with the main branch (or the head of
> development) the SCM software will create a single commit with all the
> changes applied.

I use git everyday and?

> What you're arguing is the model that subversion and CVS had, where each
> commit is visible to anyone, no matter if complete, tested or
> functional. Either or you commit something incomplete, or you keep your
> changes to yourself (backing up in a zip and other esoteric procedures)
> and work as if no SCM was available to you.
>
> This use of a DSCM as a SCM is a regression to all efects.

Miguel, I am sure that we are not in contradiction. De verdad.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Apr 15, 2011, at 10:17 PM, Alexandre Bergel wrote:

>> I can't believe that you aren't willing to learn about Software versioning ... that is really incredible to me...
>
> Dale, this is not about not willing to learn. I read and learn the whole day long. I have read the wikipage about versioning and revision. I also have read many many software engineering books. I am perfectly fine with the version number schema you wish to give to the browser. I am not sentimentally attached to mine for the browser. As the wikipage you give says, there are several different version naming schemas.
>
> What is important for me is to move on, fixing bugs, and answering to questions asked by users. I have received many questions and suggestions for improvement. So far, I feel blocked because tests are not green. Apparently printing a config info produce a slightly different result.
>
> Whereas I perfectly trust many of the decisions you made, keeping the tests green or yellow for a short time is important for me.

Alexandre,

If you want to follow my development style, then take a look at the picture in this pdf:

  http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf

from this article:

  http://nvie.com/posts/a-successful-git-branching-model/

On the "master" timeline, there are tags listed: 0.1, 0.2, 1.0. From the article: "each time when changes are merged back into master, this is a new production release by definition." So we can infer that there were three production releases: 0.1 0.2 and 1.0.

On the "hotfixes" timeline, there was "a severe bug fixed for production: hotfix 0.2" and the fix was released to production as version 0.2.

On the "release branches" timeline, note that one version was marked as the "start of release branch for 1.0" followed by several "only bugfixes" versions followed by the release to production of tagged as 1.0.

On the "develop" timeline, there is a continuous succession of versions that eventually form the basis of release 1.0, but  is almost immediately branched back onto the "develop" timeline so that ongoing development can proceed without affecting the progress towards the release of 1.0.

Hopefully, this makes sense to you up to this point ....

This model can be very easily mapped into Metacello. From my perspective the Tag balloons on the right hand side of the diagram map DIRECTLY to Metacello versions.

For the initial release into production you would create version 0.1 (with appropriate packages and structure). Version 0.1 would be blessed as #release and declared as the #stable symbolic version. The blue dot in the diagram would correspond to the monticello version of the configuration (ConfigurationOfXXX-dkh.1.mcz) in which the release occurs.

The transition from the blue dot to the yellow would be the point at which we would "open version 1.0 for development". Version 1.0 would be blessed as #development and declared as the #development symbolic version. And each little yellow dot along the "develop" timeline would represent a commit of the ConfigurationOfXXX mcz file ... In the MetacelloBrowser, you would create a new yellow dot by using the "checkpoint dev" command.

To handle "severe production bugs" on the "hotfixes" timeline, in Metacello you would "load" version 0.1, "open version 0.2 for development" and work on developing a fix for the bug. At the point you have bugfix, you would use the "checkpoint dev" command to create configuration version with just the bugfix and creating the read dot.

The next step would be to release the hot fix into production and this would be done my setting the blessing of 0.2 to #development and declaring 0.2 as the #stable symbolic version. To create the new blue dot, you would use the "release dev" command in the MetacelloBrowser.

After the hotfix is released, it is necessary to merge the hotfix into the development branch and continue development on version 1.0.

When you have reached the point where 1.0 is ready to be released, in Metacello you restrict the set of changes made for 1.0 to bugfixes as you cycle through the alpha/beta/release cycle towards eventual production release.

For continued development on the release beyond 1.0, in Metacello, you would open 2.0 or 1.1 for development, depending upon your next target release......

SOOOOOOOOOOOOOOOOOOOOOOOOOOO, ALEXANDRE..................

Given the above detailed model and description I want you to give me a step by step description of how Tobias' bugfix should be integrated into production following my development style.

If you are unable to figure out the steps that fit with this development process then I don't think that we can work together on this project.

I am willing to answer specific questions...

From my perspective the diagram opens up some interesting possibilities for what we should/could do with MetacelloBrowser and Metacello, but if you are unable/unwilling to demonstrate your grasp of the basic principles then we cannot work together on the real interesting problems...

Dale

Updates:
        Status: Fixed
        Labels: -Product-Core Product-Browser

Comment #2 on issue 133 by [hidden email]: MetacelloBrowser: Abstract  
test not indicated
http://code.google.com/p/metacello/issues/detail?id=133

version 160.1 retracted and Tobias' change set integrated into 159.2  
(dkh.298)

> If you want to follow my development style, then take a look at the picture in this pdf:
>
>  http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf
>
> from this article:
>
>  http://nvie.com/posts/a-successful-git-branching-model/

Ok, this makes sense to me.

> On the "master" timeline, there are tags listed: 0.1, 0.2, 1.0. From the article: "each time when changes are merged back into master, this is a new production release by definition." So we can infer that there were three production releases: 0.1 0.2 and 1.0.
>
> On the "hotfixes" timeline, there was "a severe bug fixed for production: hotfix 0.2" and the fix was released to production as version 0.2.
>
> On the "release branches" timeline, note that one version was marked as the "start of release branch for 1.0" followed by several "only bugfixes" versions followed by the release to production of tagged as 1.0.
>
> On the "develop" timeline, there is a continuous succession of versions that eventually form the basis of release 1.0, but  is almost immediately branched back onto the "develop" timeline so that ongoing development can proceed without affecting the progress towards the release of 1.0.
>
> Hopefully, this makes sense to you up to this point ....

It does.

One question depends on whether you consider Tobias' bugs as severe or not. Consider than they are severe, you would then create a stable 1.59.2 (as you did today actually).
If there would not be considered as severe, then they could be incorporated in the development branch, something like 1.61 or 1.60.1 (as I did).

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Apr 17, 2011, at 5:20 PM, Alexandre Bergel wrote:

Yes, the issue doesn't necessarily have to be severe .... Development was ongoing in 1.60, so one would do a point release, just to make the bugfix available, without getting stuck behind 1.60 ...

> If there would not be considered as severe, then they could be incorporated in the development branch, something like 1.61 or 1.60.1 (as I did).

Since 1.60 was the "open development version", then I would expect the code to be incorporated into 1.60 as 1.60 is the "next targeted release".

So a different way of putting it would be that one would create a point release (like 1.59.3) for the bugfix if you wanted the fix to be available before 1.60 was ready for release otherwise incorporate the fix into 1.60. Note that if there were several pending issues slated to be fixed, then 1.59.3 could be kept open to incorporate all of the bugfixes in one release ...

It's worth noting that I think using branches (as described in "the great branching experiment") will help to improve the process. If I had branched 1.60 from the start (as I have just done), then is should be easier to view the trunk 1.60 as being an accumulation point for bugfixes targetted at the next release ...

Dale

Yes, an efficient branching support is indeed necessary
I will test your latest improvement.

Alexandre


On 17 Apr 2011, at 20:08, Dale Henrichs wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.