Skip to content
This repository has been archived by the owner on May 14, 2021. It is now read-only.

Commit

Permalink
depend on pom-imglib2-4.2-SNAPSHOT including
Browse files Browse the repository at this point in the history 
imglib2-realtransform-2.0.0-beta28-SNAPSHOT
  • Loading branch information
@axtimwalde
axtimwalde committed Oct 25, 2014
1 parent ec18de4 commit c147b7c
Show file tree
Hide file tree
Showing 3 changed files with 3 additions and 3 deletions.
2 changes: 1 addition & 1 deletion pom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
<parent>
<groupId>net.imglib2</groupId>
<artifactId>pom-imglib2</artifactId>
<version>3.2</version>
<version>4.2-SNAPSHOT</version>
</parent>

<artifactId>imglib2-ui</artifactId>
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/net/imglib2/ui/MultiResolutionRenderer.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -198,6 +198,6 @@ protected static < T, A extends AffineGet & Concatenable< AffineGet > > RandomAc
sourceToScreen.concatenate( viewerTransform );
sourceToScreen.concatenate( source.getSourceTransform() );

return RealViews.constantAffine( img, sourceToScreen );
return RealViews.affine( img, sourceToScreen );
}
}
2 changes: 1 addition & 1 deletion src/main/java/net/imglib2/ui/SimpleRenderer.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,6 @@ protected static < T, A extends AffineGet & Concatenable< AffineGet > > RandomAc
transformType.set( sourceToScreen, viewerTransform );
sourceToScreen.concatenate( source.getSourceTransform() );

return RealViews.constantAffine( img, sourceToScreen );
return RealViews.affine( img, sourceToScreen );
}
}

5 comments on commit c147b7c

@dscho
Copy link

@dscho dscho commented on c147b7c Oct 25, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As pointed out in another commit's comment, it is not in our best interest to do this. Switching from fully reproducible builds to SNAPSHOT couplings would only destabilize the project. Let's switch back to release couplings (we discussed the need for this at length during last week's hackathon) and leave temporary SNAPSHOT couplings exclusively in topic branches, paying close attention to replacing those commits with release coupling ones before merging to master.

@axtimwalde
Copy link
Member Author

@axtimwalde axtimwalde commented on c147b7c Oct 25, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ctrueden
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Stephan,

I realized that, with that policy, using master for anything else than
release versions becomes pointless.

The master branch is definitely for more than only releases [1]. It is totally OK to do active development on master. The rule that Jenkins enforces is merely that you have no SNAPSHOT dependency couplings.

I think of master as the latest official codebase [2]. It will always compile, producing the same result both now and in the future (i.e., a reproducible build). And ideally, the unit tests will also all pass at every commit [3]. Master is always "release ready" but never a "release"—it may be in a less well-tested state, or have other transient brokenness.

Personally, I push changes directly to master a lot. However, I try to do this only for "single-commit" additions and changes, such as individual bug-fixes. If you have a set of related commits, a topic branch is better because: A) it provides documentation of the fact that the changes are all related—though you must merge it with git merge --no-ff to ensure git does not perform a fast-forward style merge; and B) unlike master, you can rewrite the commits on a topic branch to make the history cleaner.

All of that said, you are welcome to push directly to master whenever you want, as long as the build stays reproducible. If you need SNAPSHOT couplings, use a topic branch. You can either: A) start the branch with a WIP commit changing the desired dependency version(s) to LATEST; or B) use the dev profiles, creating an empty ~/.scijava/dev.imglib2 file to trigger SNAPSHOT couplings of all ImgLib2 dependencies. Either way, once you release the upstream components, the downstream component's topic branch needs to be rewritten to begin with a commit that bumps the affected dependency versions to the new release versions.

Earlier this week, Johannes and I discussed how to make this easier via an Eclipse plugin, and we filed an issue so that we don't forget. It will have to wait till later though.

Lastly, we want to enhance the Reproducible builds page to document this better. Once you have fully wrapped your head around all this, it would be awesome if you could take a crack at it. Otherwise, I'll get to it eventually, though I need to create the related Architecture page first.

Regards,
Curtis

[1] The OME project uses their master branch only for releases, opting instead to have multiple integration branches for different lines of development. This approach solves many problems while creating many others.

[2] In contrast to OME, the SciJava software projects opt to always use master as the One True Integration Branch (TM), which means "merge early, merge often"! As long as the build is reproducible! The downside is that we do not and cannot maintain multiple release lines (e.g., Python 2.x and Python 3.x; or OME 4.x and OME 5.x). The ramification is that when a new major version (in SemVer terms) is released, we must update all downstream code on the respective master branches as soon as possible. The Melting Pot will be of paramount help here.

[3] One great advantage of this approach is that git bisect debugging works properly.

@dscho
Copy link

@dscho dscho commented on c147b7c Oct 25, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too late

Well, yes and no. Yes: master cannot be rewound, not if you want to develop a project collaboratively. No: it is not too late to implement the lessons taught by Curtis at the hackathon in the future.

The next commit already fixes this.

I am really glad, but please note that it should be avoided in the future to do these things on master. Remember, we are using Git in a collaborative fashion, implying that sometimes it is a little more demanding on the individual developer in order to lower the overall burden of the developers working together.

you would have to switch to development branches as soon as changes are introduced to more than a single project.

Actually, Curtis pointed out at the hackathon (and I was in awe how well he expressed it, much better than I ever could) that you should switch to development branches as soon as non-trivial changes are introduced. Even if only one project is involved. Remember, this is a hard-earned lesson, it is not something some BDFL lightly dictated. It really makes development much easier to apply just a little discipline before actually modifying code. And even if the code is already modified, even if changes are committed, as long as you did not push to master, a simple git branch -m oh-i-wanted-to-start-a-topic-branch will get you back on track. Git is a powerful tool and not really hard to use, at least when you have the basics down.

If it turns out this way, I'd prefer a 'release' branch for each project instead of using master as a release branch that is monitored and built by Jenkins.

This has been tried before, but it only complicates things. Just look at it this way: release vs master is just a name change. So you should ask yourself: what is master supposed to be when we have a release branch? Is it another integration branch? If so, integrating what and to what end? As pointed out by Curtis at the hackathon, a single integration branch is really what we need here: this is the main development line leading up to the next version.

In that light, you should look at the changes you want on master asking the question: "Do I want these code changes in the next release verbatim?" In the case of SNAPSHOT couplings it is very easy to answer this question with "No", I am sure you agree by now.

That really means that all of the development should happen on topic branches unless easily committed as one or two really obvious commits whose corresponding diffs contribute to the obviousness.

And it is easy: git checkout -b my-new-topic.

Of course those topic branches should be rewritten according to the documentation I provided here. Again, this requires a little more discipline on the side of the individual developer, I agree, but just look at the benefit: it is so much easier to work together, to leverage code review (i.e. to actually get the most out of multiple people working together), and to have a clean history that serves as more than just modifying code: it is also a good documentation from which new developers can learn.

@dscho
Copy link

@dscho dscho commented on c147b7c Oct 25, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In contrast to OME, the SciJava software projects opt to always use master as the One True Integration Branch (TM), which means "merge early, merge often"! As long as the build is reproducible! The downside is that we do not and cannot maintain multiple release lines (e.g., Python 2.x and Python 3.x; or OME 4.x and OME 5.x).

Thanks for pointing that out @ctrueden. Please note that we are not at liberty to change our process there because ImageJ 1.x' architecture dictates that we use one single PluginClassLoader that loads all of the plugins' and their dependencies' classes. That means that we essentially cannot have multiple different release lines.

Please sign in to comment.