Hi Hilaire,
When I load updates, I need to manually merge your newer version. Apparently you used two different versions that both have the number 12, one from June 2nd and one from June 15. That is rather confusing. So what went wrong with your package history?
- Bert -
On 15.06.2010, at 21:59, commits@source.squeak.org wrote:
Bert Freudenberg uploaded a new version of DrGeoII-Core to project Etoys: http://source.squeak.org/etoys/DrGeoII-Core-HilaireFernandes.16.mcz
==================== Summary ====================
Name: DrGeoII-Core-HilaireFernandes.16 Author: HilaireFernandes Time: 15 June 2010, 10:40:51.881 pm UUID: a6dc1f0e-5d02-4105-afde-5de204b9b665 Ancestors: DrGeoII-Core-HilaireFernandes.15
Fix in the create multiple mode Fix in the parallel and perpendicular creation mode.
=============== Diff against DrGeoII-Core-HilaireFernandes.15 ===============
Item was changed: ----- Method: DrGBuildTool>>reset (in category 'updating') ----- reset super reset. self stopBlinking.
- self builder reset.
- selectedCostumes := OrderedCollection new!
- self builder reset!
Item was changed: ----- Method: DrGParallelBuilder>>isWanted: (in category 'testing') ----- isWanted: aMathItemCollection aMathItemCollection ifEmpty: [^false].
- ^ (aMathItemCollection first isPointItem and: [pointA isNil])
or: [aMathItemCollection first isDirectionItem and: [direction isNil]]
- ^ (aMathItemCollection first isPointItem
and: [aMathItemCollection first ~= pointA])or: [aMathItemCollection first isDirectionItemand: [aMathItemCollection first ~= direction]]!
Item was changed: ----- Method: DrGeoDomain>>addModelItemsToWindowMenu: (in category 'user interface') ----- addModelItemsToWindowMenu: aMenu aMenu addLine. aMenu add: 'About Dr. Geo II...' target: self selector: #inform:
argument: 'Copyright 1996-2010 Hilaire Fernandes'!
argument: 'Copyright 1996-2009 Hilaire Fernandes'!Item was removed:
- ----- Method: DrGeoDomain>>updateDirtyMathItems (in category 'deprecated') -----
- updateDirtyMathItems
- factory updateDirtyMathItems.
- self triggerEvent: #updatedDirtyItems!
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else?
Hilaire
Bert Freudenberg a écrit :
Hi Hilaire,
When I load updates, I need to manually merge your newer version. Apparently you used two different versions that both have the number 12, one from June 2nd and one from June 15. That is rather confusing. So what went wrong with your package history?
- Bert -
On 19.06.2010, at 17:28, Hilaire Fernandes wrote:
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else? Hilaire
You published a version 12 in the etoys repo, dated June 2.
On June 15, you took version 11 and started developing again, from that branch you published the current version.
So the current version does not have the original version 12 as a direct ancestor - that's where the problems come from. No automatic loading or merging is possible if a later version is not a child/grandchild of the previous version.
So this is breaking the automatic updating. You should always develop on a single version - branching takes extra effort.
- Bert -
Bert Freudenberg a écrit :
Hi Hilaire, When I load updates, I need to manually merge your newer version. Apparently you used two different versions that both have the number 12, one from June 2nd and one from June 15. That is rather confusing. So what went wrong with your package history?
- Bert -
On 19.06.2010, at 19:01, Bert Freudenberg wrote:
On 19.06.2010, at 17:28, Hilaire Fernandes wrote:
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else? Hilaire
You published a version 12 in the etoys repo, dated June 2.
On June 15, you took version 11 and started developing again, from that branch you published the current version.
So the current version does not have the original version 12 as a direct ancestor - that's where the problems come from. No automatic loading or merging is possible if a later version is not a child/grandchild of the previous version.
So this is breaking the automatic updating. You should always develop on a single version - branching takes extra effort.
- Bert -
What you should do is merge the version 12 from the etoys repo into your latest version. Then publish that as a new version to your own repository, and *copy* it to the etoys repository (do not save it again).
- Bert -
This multirepository for identic source code is unsane. Why can't you just grab a copy from the upsteam repository when I notice one for you?
Hilaire
Bert Freudenberg a écrit :
On 19.06.2010, at 19:01, Bert Freudenberg wrote:
On 19.06.2010, at 17:28, Hilaire Fernandes wrote:
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else? Hilaire
You published a version 12 in the etoys repo, dated June 2.
On June 15, you took version 11 and started developing again, from that branch you published the current version.
So the current version does not have the original version 12 as a direct ancestor - that's where the problems come from. No automatic loading or merging is possible if a later version is not a child/grandchild of the previous version.
So this is breaking the automatic updating. You should always develop on a single version - branching takes extra effort.
- Bert -
What you should do is merge the version 12 from the etoys repo into your latest version. Then publish that as a new version to your own repository, and *copy* it to the etoys repository (do not save it again).
- Bert -
Because that doesn't solve the problem, and creates extra work for us. Also, you are surely testing in the Etoys image anyway, right?
You simply need to copy your latest version to etoys. It's one click in Monticello on the "copy" button.
If you always do this, instead of saving a separate version for etoys, you will never run into this problem again.
- Bert -
On 19.06.2010, at 19:30, Hilaire Fernandes wrote:
This multirepository for identic source code is unsane. Why can't you just grab a copy from the upsteam repository when I notice one for you?
Hilaire
Bert Freudenberg a écrit :
On 19.06.2010, at 19:01, Bert Freudenberg wrote:
On 19.06.2010, at 17:28, Hilaire Fernandes wrote:
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else? Hilaire
You published a version 12 in the etoys repo, dated June 2.
On June 15, you took version 11 and started developing again, from that branch you published the current version.
So the current version does not have the original version 12 as a direct ancestor - that's where the problems come from. No automatic loading or merging is possible if a later version is not a child/grandchild of the previous version.
So this is breaking the automatic updating. You should always develop on a single version - branching takes extra effort.
- Bert -
What you should do is merge the version 12 from the etoys repo into your latest version. Then publish that as a new version to your own repository, and *copy* it to the etoys repository (do not save it again).
- Bert -
On 19.06.2010, at 19:58, Bert Freudenberg wrote:
Because that doesn't solve the problem, and creates extra work for us. Also, you are surely testing in the Etoys image anyway, right?
You simply need to copy your latest version to etoys. It's one click in Monticello on the "copy" button.
If you always do this, instead of saving a separate version for etoys, you will never run into this problem again.
- Bert -
Besides, your upstream version is licensed as LGPL. Only you as the author can release it under a different license. By publishing the package to the Etoys inbox you assert that you have the full rights to dual-license it as MIT.
Of course, that also means that you cannot relicense patches that someone else contributes to your code under the LGPL (unless that contributor would also release them under MIT for Etoys).
- Bert -
On 19.06.2010, at 19:30, Hilaire Fernandes wrote:
This multirepository for identic source code is unsane. Why can't you just grab a copy from the upsteam repository when I notice one for you?
Hilaire
Bert Freudenberg a écrit :
On 19.06.2010, at 19:01, Bert Freudenberg wrote:
On 19.06.2010, at 17:28, Hilaire Fernandes wrote:
Hi Bert,
I can't see duplicated #12 package. What I see is jump in version number in the Etoys repository. For example, DrGeoII-core version jumped from #12 to #15. It is expected as the development is done in the DrGeo repository, then when I am happy with the changed code, I push a new version in DrGeo repository.
What else? Hilaire
You published a version 12 in the etoys repo, dated June 2.
On June 15, you took version 11 and started developing again, from that branch you published the current version.
So the current version does not have the original version 12 as a direct ancestor - that's where the problems come from. No automatic loading or merging is possible if a later version is not a child/grandchild of the previous version.
So this is breaking the automatic updating. You should always develop on a single version - branching takes extra effort.
- Bert -
What you should do is merge the version 12 from the etoys repo into your latest version. Then publish that as a new version to your own repository, and *copy* it to the etoys repository (do not save it again).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Bert Freudenberg a écrit :
Because that doesn't solve the problem, and creates extra work for us. Also, you are surely testing in the Etoys image anyway, right?
which extra work?
You simply need to copy your latest version to etoys. It's one click in Monticello on the "copy" button.
If you always do this, instead of saving a separate version for etoys, you will never run into this problem again.
Aha, this hidden copy button in the right. Indeed, this is the problem I saw without the solution.
I just copy a newer version, please check if it is ok.
Hilaire
On 19.06.2010, at 20:28, Hilaire Fernandes wrote:
Bert Freudenberg a écrit :
Because that doesn't solve the problem, and creates extra work for us. Also, you are surely testing in the Etoys image anyway, right?
which extra work?
The work of hunting down these versions from repositories we normally do not work with. And there is the licensing problem I mentioned in my follow-up message. Only you can submit these versions under MIT into Etoys.
You simply need to copy your latest version to etoys. It's one click in Monticello on the "copy" button. If you always do this, instead of saving a separate version for etoys, you will never run into this problem again.
Aha, this hidden copy button in the right. Indeed, this is the problem I saw without the solution.
I just copy a newer version, please check if it is ok.
Hilaire
It is the same version as in the drgeo repo (UUID 9d8afd5f-0432-4e39-b2ff-8414261fcde4), so that is good. This is how you can submit future versions.
I will remove the bad versions (12 and 16) from the Etoys repo.
To avoid confusion I will wait until you made a version 17 and pushed that into the inbox. But since you are working on this I'm sure it won't take you long :)
Once there is a version > 16 I will move it to the Etoys repo.
Sounds fair?
- Bert -
Bert Freudenberg a écrit :
To avoid confusion I will wait until you made a version 17 and pushed that into the inbox. But since you are working on this I'm sure it won't take you long :)
I am done for now with DrGeo, I fix these two bugs I discover recently using the software in a math lesson. I should not have opportunity to work on it for several weeks.
Once there is a version > 16 I will move it to the Etoys repo.
Sounds fair?
Yes.
Thanks
Hilaire
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Hilaire Fernandes