Breaking API changes and BOM version bumps

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Breaking API changes and BOM version bumps

Mark Hiner
Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Jean-Yves Tinevez-2
Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked.
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Tobias Pietzsch
Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
best regards,
Tobias

On 16 Mar 2015, at 21:58, <[hidden email]> <[hidden email]> wrote:

Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked. 
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Mark Hiner
>Next pizza & beer are on me.

You should rename packages more often! :)

Neither of you should be hard on yourselves - our release history is filled with mistakes like this, and worse. Until dependency convergence is automatically tied to the release process, there will be more.

>If you could point me to packages that are hit by the imglib-algorithm change

Potentially affected components that I know of:
BDV-core
TrackMate
imglib2-tests
imglib2-algorithm-gpl

I really do have to fix ij1-patcher before uploading anyway, and just adding back the moved classes would be minimal effort. So the situation is far from dire.

Best,
Mark

On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <[hidden email]> wrote:
Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
best regards,
Tobias

On 16 Mar 2015, at 21:58, <[hidden email]> <[hidden email]> wrote:

Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked. 
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Tobias Pietzsch
Hi Mark,

imglib2-tests and
imglib2-algorithm-gpl
are fixed already.

I’ll check BDV and TrackMate tommorrow.

all the best,
Tobias

On 17 Mar 2015, at 00:03, Mark Hiner <[hidden email]> wrote:

>Next pizza & beer are on me.

You should rename packages more often! :)

Neither of you should be hard on yourselves - our release history is filled with mistakes like this, and worse. Until dependency convergence is automatically tied to the release process, there will be more.

>If you could point me to packages that are hit by the imglib-algorithm change

Potentially affected components that I know of:
BDV-core
TrackMate
imglib2-tests
imglib2-algorithm-gpl

I really do have to fix ij1-patcher before uploading anyway, and just adding back the moved classes would be minimal effort. So the situation is far from dire.

Best,
Mark

On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <[hidden email]> wrote:
Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
best regards,
Tobias

On 16 Mar 2015, at 21:58, <[hidden email]> <[hidden email]> wrote:

Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked. 
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Mark Hiner
Hi Tobias,

>I really do have to fix ij1-patcher before uploading anyway

Just wanted to let you know that the latest ij1-patcher and imagej-legacy are released.

Let me know if you run into any problems!

Thanks,
Mark

On Mon, Mar 16, 2015 at 6:06 PM, Tobias Pietzsch <[hidden email]> wrote:
Hi Mark,

imglib2-tests and
imglib2-algorithm-gpl
are fixed already.

I’ll check BDV and TrackMate tommorrow.

all the best,
Tobias

On 17 Mar 2015, at 00:03, Mark Hiner <[hidden email]> wrote:

>Next pizza & beer are on me.

You should rename packages more often! :)

Neither of you should be hard on yourselves - our release history is filled with mistakes like this, and worse. Until dependency convergence is automatically tied to the release process, there will be more.

>If you could point me to packages that are hit by the imglib-algorithm change

Potentially affected components that I know of:
BDV-core
TrackMate
imglib2-tests
imglib2-algorithm-gpl

I really do have to fix ij1-patcher before uploading anyway, and just adding back the moved classes would be minimal effort. So the situation is far from dire.

Best,
Mark

On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <[hidden email]> wrote:
Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
best regards,
Tobias

On 16 Mar 2015, at 21:58, <[hidden email]> <[hidden email]> wrote:

Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked. 
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Jean-Yves Tinevez-2

> On 18 mars 2015, at 17:42, Mark Hiner <[hidden email]> wrote:
>
> Hi Tobias,
>
> >I really do have to fix ij1-patcher before uploading anyway
>
> Just wanted to let you know that the latest ij1-patcher and imagej-legacy are released.
>
> Let me know if you run into any problems!

Hi all

Quick question: I am looking on the headless problem I mention in another mail.
Are these 2 jars involved in the headless option? If not, what one is?
Best
jy
_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API changes and BOM version bumps

Tobias Pietzsch
In reply to this post by Mark Hiner
Hi Mark,

I just released
pom-bigdataviewer 1.1.2
bigdataviewer-core 1.0.8
bigdataviewer_fiji 1.0.10
bigdataviewer-server 1.0.3
Parent of pom-bigdataviewer 1.1.2 is pom-fiji 8.0.0.

best regards,
Tobias

On 18 Mar 2015, at 17:42, Mark Hiner <[hidden email]> wrote:

Hi Tobias,

>I really do have to fix ij1-patcher before uploading anyway

Just wanted to let you know that the latest ij1-patcher and imagej-legacy are released.

Let me know if you run into any problems!

Thanks,
Mark

On Mon, Mar 16, 2015 at 6:06 PM, Tobias Pietzsch <[hidden email]> wrote:
Hi Mark,

imglib2-tests and
imglib2-algorithm-gpl
are fixed already.

I’ll check BDV and TrackMate tommorrow.

all the best,
Tobias

On 17 Mar 2015, at 00:03, Mark Hiner <[hidden email]> wrote:

>Next pizza & beer are on me.

You should rename packages more often! :)

Neither of you should be hard on yourselves - our release history is filled with mistakes like this, and worse. Until dependency convergence is automatically tied to the release process, there will be more.

>If you could point me to packages that are hit by the imglib-algorithm change

Potentially affected components that I know of:
BDV-core
TrackMate
imglib2-tests
imglib2-algorithm-gpl

I really do have to fix ij1-patcher before uploading anyway, and just adding back the moved classes would be minimal effort. So the situation is far from dire.

Best,
Mark

On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <[hidden email]> wrote:
Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
best regards,
Tobias

On 16 Mar 2015, at 21:58, <[hidden email]> <[hidden email]> wrote:

Fudge fudge fudge I did this.
I am really sorry this is something I vastly overlooked. 
Next pizza & beer are on me.

De : [hidden email]
Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
À : [hidden email], [hidden email]
Cc : [hidden email]

Hi all,

 I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.

 Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.

 Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.

 For those interested, there are two possible solutions:

1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
or
2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.

 Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).

 Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.

 The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.

Best,
Mark


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

signature.asc (465 bytes) Download Attachment