Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Esteban A. Maringolo]

On 19/06/2018 09:06, Norbert Hartl wrote:

>> We can agree that there is no hard rule on versionning, do we? But I
>> try to follow the following guidelines (delta my own interpretation
>> that adds some subjectivity :P)
>> - Major Version will change when we break backwards compatibility
>> - Minor Version will change when new features are added
>> - Otherwise, patch version will change.
>>
> There is only one hard rule for me and that is knowing about the risk to
> take. So if we take the patch version it should only include important
> bug fixes and nothing else. I would argue that only #864, #862, #858 and
> #854 qualify for such a patch if at all. Not sure about #860 because the
> title is not specific enough. 
> The point for me is that I want my project to rely on something like
> 1.1.x because I don’t want anything to change that breaks my software.
> And I can tell you that most developers underestimate the side-effects
> of changes. 

+1 to this.

Only by introducing a new feature you MUST increment the minor version.

>> Now, this is the kind of subjective topic that starts a flamewar, but
>> I’d prefer to use my time on somewhat else ^^.
> 
> You may not like to talk about these things but I do. And you should
> listen. I have no use for an environment where people only care about
> coding new cool stuff.
> If it would be like this I would quit all my
> pharo businesses, move to mainstream and would use pharo only for
> hobbyist projects because that would be the level that can be met.

I've used commercial Smalltalks before Pharo and VW for the last year,
and although they're _ages_ behind some of the "modern" stuff in Pharo,
they never compromise version semantics regarding these things.

And if I give it a second thought I can point to other open-source
non-smalltak big projects/libraries which are also cool but also follow
strict versioning, and being bigger the cascade effect of changing
artifacts semantics is way bigger.


Please take this comment with a grain of salt, it's not a critic of all
the work done in Iceberg or other projects, but it seems that these kind
of "meta" (aka "PM", "strategy", or anything non-coding) discussions are
avoided or muted, and they shouldn't.


Regards,


-- 
Esteban A. Maringolo

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Norbert Hartl]

> Am 19.06.2018 um 15:22 schrieb Guillermo Polito :
> 
> 
> On Tue, Jun 19, 2018 at 2:07 PM Norbert Hartl  > wrote:
> Hi,
> 
> let me wear the project manager hat for a moment.
> 
> let me too, because the fact that I'm younger does not mean I don't know, 
> right? :)
>  
It has more to do with experience then with age. Well, the one thing enables 
sometimes the other but there is no strict causality, right.

> 
>> Am 19.06.2018 um 10:59 schrieb Guillermo Polito > >:
>> 
>> Hi,
>> 
>> About why 1.1.1 and not 1.2.0. It’s not about cheap or not, but about 
>> semantics :)
> 
> for me „caring about semantics“ is just one of the top ten justifications 
> developers use for the changes they did.
> 
> Maybe, and putting the hat of project manager is usually a justification for 
> somebody that is not good at technical stuff.
> But I know that's not like it, so please let's not enter into this, I've felt 
> a little insulted by this comment...
>  
That is pretty clear by what you wrote. It wasn’t meant to be personal so 
please don’t take it like that. So do I. 
> 
>> We can agree that there is no hard rule on versionning, do we? But I try to 
>> follow the following guidelines (delta my own interpretation that adds some 
>> subjectivity :P)
>> - Major Version will change when we break backwards compatibility
>> - Minor Version will change when new features are added
>> - Otherwise, patch version will change.
>> 
> There is only one hard rule for me and that is knowing about the risk to take.
> 
> That's a matter of conventions. We agree that version 1.1.x is compatible 
> with 1.1.y.
>  
> So if we take the patch version it should only include important bug fixes 
> and nothing else. I would argue that only #864, #862, #858 and #854 qualify 
> for such a patch if at all.
> 
> So they are to my view. They should not introduce any compatibility issue.
> And if they do, that's an error, but we are too few helping here, doing our 
> best...
>  
My mail was meant to be a plea for exactly this. If you don’t think the hot-fix 
(I like that much more than patch) solves a show stopper for a lot of users of 
this version you don’t put it in a patch version. If it is in the slightest 
sense an improvement don’t put into a patch version but a minor on. Because I 
don’t want to have my stuff broken but I choose to update in order to get the 
improvement hence a deliberate action. If all of these commits are hot-fixes 
then take my big excuse for bringing this up.

> Not sure about #860 because the title is not specific enough. 
> 
> Please, I'll let you judge it for yourself
> 
> https://github.com/pharo-vcs/iceberg/pull/860/files 
> 
> 
> But to me that change applies to patch. It actually fixes a compatibility 
> issue that was introduced in 1.1.0.
>  
> The point for me is that I want my project to rely on something like 1.1.x 
> because I don’t want anything to change that breaks my software. And I can 
> tell you that most developers underestimate the side-effects of changes. 
> 
> I'm well aware of this. But do you have a concrete issue?
>  
For what?

> 
>> So I don’t assign a new version number regarding the number of changes but 
>> about what they mean...
> 
> To mean they mean it is a risk to use that version and you define how big 
> that is.
> 
> We are trying to do weekly releases, we could do better but again. I can 
> count with my hand fingers people contributing with actual commits and issues 
> in the issue tracker.
>  
This time it is not about having more but less in a version.
> 
>> Now, I considered myself this release as a patch because mostly little bugs 
>> here and there were fixed.
>> Moreover, one of the changes done in the credentials manager was to 
>> *recover* some backwards compatibility for people setting up credentials in 
>> settings files.
>> Of course, to this we add to this that my own interpretation saying that the 
>> changes do not break compatibility nor add features :)
>> 
> You see you said „mostly bugs“ and that is the error already.
> 
> I'm sorry for not being perfect...
>  
> I mean we come from an amateurish behaviour that we change released artefacts.
> 
> I assure you I do my best on it, and I'm one of the first that cries aloud 
> when there are versionning and dependencies problems.
> What I do not understand if this mail was meant as a lesson for the community 
> or should I take it personally...
>  
I know you do your best. And I know that you are a really good developer that 
does great stuff all the time. It is neither meant as a lesson nor something 
you should take personally. I do not often raise my wishes because I always 
need to assurance it is something really important and not something I want out 
of my current mood. But this is something I have no doubt about so I bring it 
up. And I do all of this for quite some time and that does count, 

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Tudor Girba]

Hi,

Indeed. Something went amiss in this email exchange. But, I really do not think 
that you are in disagreement.

Cheers,
Doru



> On Jun 19, 2018, at 4:09 PM, Christophe Demarey  
> wrote:
> 
> Hi Norbert,
> 
>> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
>> 
>> I have no use for an environment where people only care about coding new 
>> cool stuff. If it would be like this I would quit all my pharo businesses, 
>> move to mainstream and would use pharo only for hobbyist projects because 
>> that would be the level that can be met.
> 
> I do not think Guille has this state of mind. He spends time to write lot of 
> tests for code other people wrote (not the funniest part), to clean code in 
> the image (old code, bad dependencies, better API), to improve existing 
> stuff, answering questions on the ML, and so on.
> He is one of the few people that really tries to push semantic versioning. He 
> could have made some errors (like everyone) but I find your sentence not fair 
> for him.
> 
> Regards,
> Christophe

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Christophe Demarey]

Hi Norbert,

> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
> 
> I have no use for an environment where people only care about coding new cool 
> stuff. If it would be like this I would quit all my pharo businesses, move to 
> mainstream and would use pharo only for hobbyist projects because that would 
> be the level that can be met.

I do not think Guille has this state of mind. He spends time to write lot of 
tests for code other people wrote (not the funniest part), to clean code in the 
image (old code, bad dependencies, better API), to improve existing stuff, 
answering questions on the ML, and so on.
He is one of the few people that really tries to push semantic versioning. He 
could have made some errors (like everyone) but I find your sentence not fair 
for him.

Regards,
Christophe

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Guillermo Polito]

On Tue, Jun 19, 2018 at 2:07 PM Norbert Hartl  wrote:

> Hi,
>
> let me wear the project manager hat for a moment.
>

let me too, because the fact that I'm younger does not mean I don't know,
right? :)


>
> Am 19.06.2018 um 10:59 schrieb Guillermo Polito  >:
>
> Hi,
>
> About why 1.1.1 and not 1.2.0. It’s not about cheap or not, but about
> semantics :)
>
>
> for me „caring about semantics“ is just one of the top ten justifications
> developers use for the changes they did.
>

Maybe, and putting the hat of project manager is usually a justification
for somebody that is not good at technical stuff.
But I know that's not like it, so please let's not enter into this, I've
felt a little insulted by this comment...


>
> We can agree that there is no hard rule on versionning, do we? But I try
> to follow the following guidelines (delta my own interpretation that adds
> some subjectivity :P)
> - Major Version will change when we break backwards compatibility
> - Minor Version will change when new features are added
> - Otherwise, patch version will change.
>
> There is only one hard rule for me and that is knowing about the risk to
> take.
>

That's a matter of conventions. We agree that version 1.1.x is compatible
with 1.1.y.


> So if we take the patch version it should only include important bug fixes
> and nothing else. I would argue that only #864, #862, #858 and #854 qualify
> for such a patch if at all.
>

So they are to my view. They should not introduce any compatibility issue.
And if they do, that's an error, but we are too few helping here, doing our
best...


> Not sure about #860 because the title is not specific enough.
>

Please, I'll let you judge it for yourself

https://github.com/pharo-vcs/iceberg/pull/860/files

But to me that change applies to patch. It actually fixes a compatibility
issue that was introduced in 1.1.0.


> The point for me is that I want my project to rely on something like 1.1.x
> because I don’t want anything to change that breaks my software. And I can
> tell you that most developers underestimate the side-effects of changes.
>

I'm well aware of this. But do you have a concrete issue?


>
> So I don’t assign a new version number regarding the number of changes but
> about what they mean...
>
>
> To mean they mean it is a risk to use that version and you define how big
> that is.
>

We are trying to do weekly releases, we could do better but again. I can
count with my hand fingers people contributing with actual commits and
issues in the issue tracker.


>
> Now, I considered myself this release as a patch because mostly little
> bugs here and there were fixed.
> Moreover, one of the changes done in the credentials manager was to
> *recover* some backwards compatibility for people setting up credentials in
> settings files.
> Of course, to this we add to this that my own interpretation saying that
> the changes do not break compatibility nor add features :)
>
> You see you said „mostly bugs“ and that is the error already.
>

I'm sorry for not being perfect...


> I mean we come from an amateurish behaviour that we change released
> artefacts.
>

I assure you I do my best on it, and I'm one of the first that cries aloud
when there are versionning and dependencies problems.
What I do not understand if this mail was meant as a lesson for the
community or should I take it personally...


> That is not discussable just a no-go.
>

I know and I'm against it. So we agree, right?


> The reason was it would have wasted a huge amount of time to do a new
> version. So ok it was a loose-loose situation. Now we can do it better and
> I want something far less amateurish. So you can discuss your semantics
> about what major and minor versions in pharo mean but patch needs to be the
> definition of the combination: least risk - highest value.
>

Would you help us measuring the risk?


>
> Now, this is the kind of subjective topic that starts a flamewar, but I’d
> prefer to use my time on somewhat else ^^.
>
>
> You may not like to talk about these things but I do. And you should
> listen.
>

I mostly do [enjoy such discussions] but what I learn from this discussion
is:
 - you think I'm stupid, or young, or both, so I don't know
 - we are all amateurs


> I have no use for an environment where people only care about coding new
> cool stuff.
>

I'm fu*** trying to make Iceberg as stable as possible, If I was just
wanting to do new cool stuff I would not be doing this.

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Norbert Hartl]

Hi,

let me wear the project manager hat for a moment.

> Am 19.06.2018 um 10:59 schrieb Guillermo Polito :
> 
> Hi,
> 
> About why 1.1.1 and not 1.2.0. It’s not about cheap or not, but about 
> semantics :)

for me „caring about semantics“ is just one of the top ten justifications 
developers use for the changes they did.

> We can agree that there is no hard rule on versionning, do we? But I try to 
> follow the following guidelines (delta my own interpretation that adds some 
> subjectivity :P)
> - Major Version will change when we break backwards compatibility
> - Minor Version will change when new features are added
> - Otherwise, patch version will change.
> 
There is only one hard rule for me and that is knowing about the risk to take. 
So if we take the patch version it should only include important bug fixes and 
nothing else. I would argue that only #864, #862, #858 and #854 qualify for 
such a patch if at all. Not sure about #860 because the title is not specific 
enough. 
The point for me is that I want my project to rely on something like 1.1.x 
because I don’t want anything to change that breaks my software. And I can tell 
you that most developers underestimate the side-effects of changes. 

> So I don’t assign a new version number regarding the number of changes but 
> about what they mean...

To mean they mean it is a risk to use that version and you define how big that 
is.

> Now, I considered myself this release as a patch because mostly little bugs 
> here and there were fixed.
> Moreover, one of the changes done in the credentials manager was to *recover* 
> some backwards compatibility for people setting up credentials in settings 
> files.
> Of course, to this we add to this that my own interpretation saying that the 
> changes do not break compatibility nor add features :)
> 
You see you said „mostly bugs“ and that is the error already. I mean we come 
from an amateurish behaviour that we change released artefacts. That is not 
discussable just a no-go. The reason was it would have wasted a huge amount of 
time to do a new version. So ok it was a loose-loose situation. Now we can do 
it better and I want something far less amateurish. So you can discuss your 
semantics about what major and minor versions in pharo mean but patch needs to 
be the definition of the combination: least risk - highest value.

> Now, this is the kind of subjective topic that starts a flamewar, but I’d 
> prefer to use my time on somewhat else ^^.

You may not like to talk about these things but I do. And you should listen. I 
have no use for an environment where people only care about coding new cool 
stuff. If it would be like this I would quit all my pharo businesses, move to 
mainstream and would use pharo only for hobbyist projects because that would be 
the level that can be met.

Norbert

> In any case, I think it is more important to discuss about the numbering as 
> soon as we have a clear documentation on Iceberg's API...
> 
> Regarding the bad links, I copy-pasted the text from the PR instead from the 
> release page in Iceberg, which messes up links.
> 
> Patch version containing the following cleanups and enhancements
> 
> #864  Repairing Missing 
> repositories lead to wrong source directory
> #861  update tonel to v1.0.9
> #836  DefaultBackendType 
> class variable is unused
> #862  Iceberg tests are not 
> running in Pharo 7
> #852  Make error dialogs 
> copy-pastable
> #858  
> IceTipReadOnlyTextMorph does not allow select and copy anymore
> #850  Change Detached head 
> status from error to warning if we are on a tag
> #853  Clone dialog 
> "username" is confusing
> #860  CredentialStore API
> #854  Error in History window
> 
> Guille
> 
> On Mon, Jun 18, 2018 at 9:12 PM Torsten Bergmann  > wrote:
> Great - thank you! Might be a small patch release - but nonetheless important.
> 
> BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg. If 
> you used
>  a template you might want to consider changing it.
>  
>  
> Gesendet: Montag, 18. Juni 2018 um 17:47 Uhr
> Von: "Guillermo Polito"  >
> An: "Any question about pharo is welcome"  >, "Discusses Development of Pharo" 
> mailto:pharo-dev@lists.pharo.org>>
> Betreff: [Pharo-dev] [Ann] Iceberg v1.1.1
> Hi everybody,
>  
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
> 

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Guillermo Polito]

Hi,

About why 1.1.1 and not 1.2.0. It's not about cheap or not, but about
semantics :)
We can agree that there is no hard rule on versionning, do we? But I try to
follow the following guidelines (delta my own interpretation that adds some
subjectivity :P)
- Major Version will change when we break backwards compatibility
- Minor Version will change when new features are added
- Otherwise, patch version will change.

So I don't assign a new version number regarding the number of changes but
about what they mean...
Now, I considered myself this release as a patch because mostly little bugs
here and there were fixed.
Moreover, one of the changes done in the credentials manager was to
*recover* some backwards compatibility for people setting up credentials in
settings files.
Of course, to this we add to this that my own interpretation saying that
the changes do not break compatibility nor add features :)

Now, this is the kind of subjective topic that starts a flamewar, but I'd
prefer to use my time on somewhat else ^^.
In any case, I think it is more important to discuss about the numbering as
soon as we have a clear documentation on Iceberg's API...

Regarding the bad links, I copy-pasted the text from the PR instead from
the release page in Iceberg, which messes up links.

Patch version containing the following cleanups and enhancements

#864  Repairing Missing
repositories lead to wrong source directory
#861  update tonel to v1.0.9
#836  DefaultBackendType
class variable is unused
#862  Iceberg tests are
not running in Pharo 7
#852  Make error dialogs
copy-pastable
#858  IceTipReadOnlyTextMorph
does not allow select and copy anymore
#850  Change Detached head
status from error to warning if we are on a tag
#853  Clone dialog
"username" is confusing
#860  CredentialStore API
#854  Error in History
window

Guille

On Mon, Jun 18, 2018 at 9:12 PM Torsten Bergmann  wrote:

> Great - thank you! Might be a small patch release - but nonetheless
> important.
>
> BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg.
> If you used
>  a template you might want to consider changing it.
>
>
> *Gesendet:* Montag, 18. Juni 2018 um 17:47 Uhr
> *Von:* "Guillermo Polito" 
> *An:* "Any question about pharo is welcome" ,
> "Discusses Development of Pharo" 
> *Betreff:* [Pharo-dev] [Ann] Iceberg v1.1.1
> Hi everybody,
>
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
>
> In summary, this release fixes two issues with the new credentials
> manager, and introduces a couple of other enhancements/bugfixes.
>
> Below you will find the detailed changes log.
> Enjoy,
> Guille
>
>
> Integrate Iceberg 1.1.1
> https://pharo.fogbugz.com/f/cases/22168/Integrate-Iceberg-1-1-1
>
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.1.1
>
> #864  Repairing Missing
> repositories lead to wrong source directory
> #861  update tonel to
> v1.0.9
> #836  DefaultBackendType
> class variable is unused
> #862  Iceberg tests are
> not running in Pharo 7
> #852  Make error dialogs
> copy-pastable
> #858  IceTipReadOnlyTextMorph
> does not allow select and copy anymore
> #850  Change Detached
> head status from error to warning if we are on a tag
> #853  Clone dialog
> "username" is confusing
> #860  CredentialStore API
> #854  Error in History
> window
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
>
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Norbert Hartl]

Thanks again for the new things. Just a little maneuver critique. The amount of 
changes you did should be iceberg 1.2.0 and 1.1.1. Versions are cheap ;) and 
everything which is not really a hot-fix should be a new minor version.

Norbert


> Am 18.06.2018 um 17:47 schrieb Guillermo Polito :
> 
> Hi everybody,
> 
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
> 
> In summary, this release fixes two issues with the new credentials manager, 
> and introduces a couple of other enhancements/bugfixes.
> 
> Below you will find the detailed changes log.
> Enjoy,
> Guille
> 
> Integrate Iceberg 1.1.1
> https://pharo.fogbugz.com/f/cases/22168/Integrate-Iceberg-1-1-1 
> 
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.1.1 
> 
> #864  Repairing Missing 
> repositories lead to wrong source directory
> #861  update tonel to v1.0.9
> #836  DefaultBackendType 
> class variable is unused
> #862  Iceberg tests are not 
> running in Pharo 7
> #852  Make error dialogs 
> copy-pastable
> #858  
> IceTipReadOnlyTextMorph does not allow select and copy anymore
> #850  Change Detached head 
> status from error to warning if we are on a tag
> #853  Clone dialog 
> "username" is confusing
> #860  CredentialStore API
> #854  Error in History window
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13