I'd probably argue in favor of continuing to use SF to host all of the downloads; their metrics are fine for what we need (does anyone know what if any metrics github offers re: downloads?) and people are used to going to the SF download location for the latest NH bins.
Also, there's benefit to having one place where its simple for people to get all of the NH-related bins (core, spatial, validator, etc., etc.) and SF already contains all of these. If a user consumes more than just nh-core, its probably not a good idea to ask them to go to github to get nh-core then elsewhere entirely to get spatial, contrib, caches, etc. IMO the project benefits from having one over-arching location from which to download the entirety of the 'universe' of NH-related bins. Does anyone know if there is there a similar way to achieve this via github (to avoid the need to jump around to collect all the projects one might want to download)? Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Thu, Aug 18, 2011 at 7:31 AM, Fabio Maulo <[email protected]> wrote: > You can continue using SF for release. > > > On Thu, Aug 18, 2011 at 3:14 AM, Julian Maughan > <[email protected]>wrote: > >> Does anybody have any thoughts on where to publish the next NH release (or >> releases after 3.2.1)? I agree with keeping the SVN repository on SF for a >> while, but if we are generally moving away from SF, perhaps releases should >> be hosted elsewhere. One option is NHForge - but I don't know if this is >> stable/scalable enough, or if it provides download stats. GitHub doesn't >> seem to provide a place for releases (?) >> >> >> On 18 August 2011 05:14, Stephen Bohlen <[email protected]> wrote: >> >>> Also thinking about this from the POV of the fact that the existing SVN >>> repo URL is widely-known/posted/linked-to/etc. With this kind of an >>> approach, anyone blindly doing an svn update would get the new file and >>> (hopefully!) notice it in their working copy... >>> >>> >>> Steve Bohlen >>> [email protected] >>> http://blog.unhandled-exceptions.com >>> http://twitter.com/sbohlen >>> >>> >>> On Wed, Aug 17, 2011 at 5:11 PM, Stephen Bohlen <[email protected]>wrote: >>> >>>> Since the existing SVN repo is effectively read-only for everyone but >>>> the small group of committers, my guess is that we're "safe" just ensuring >>>> that the existing committers are told "hands off the SVN repo for the >>>> foreseeable future" but I'm also thinking of how someone new to NH would >>>> know that the SVN repo was obsolete (and this not to use it as the basis >>>> for >>>> creating patches, etc.). >>>> >>>> What about committing a text file into the root of the SVN repo named >>>> THIS_REPOSITORY_IS_OBSOLETE___DO_NOT_USE___READ_ME_FOR_DETAILS.txt that >>>> explains the location of the new github repo so that there's at least some >>>> way of new folks not making the mistake of working with this repo any >>>> longer? >>>> >>>> >>>> Steve Bohlen >>>> [email protected] >>>> http://blog.unhandled-exceptions.com >>>> http://twitter.com/sbohlen >>>> >>>> >>>> On Wed, Aug 17, 2011 at 5:02 PM, Patrick Earl <[email protected]>wrote: >>>> >>>>> On Wed, Aug 17, 2011 at 1:26 PM, Stephen Bohlen <[email protected]> >>>>> wrote: >>>>> > I think that there are probably several housekeeping issues that >>>>> still >>>>> > remain to be addressed around this process: >>>>> > >>>>> > We need to decide what to do about the disposition of the existing >>>>> SVN repo >>>>> > (shut it down completely, annotate its content as SUPERSEDED and >>>>> direct ppl >>>>> > to the git repo via a readme note in it, etc., etc.). What are >>>>> people's >>>>> > ideas about how best to handle this? Is it the case at this point >>>>> that the >>>>> > entire contents of the SVN repo are in git (e.g., there have been no >>>>> > subsequent commits to the SVN repo since the import to git)? >>>>> >>>>> There have been no new commits and all branches and tags have been >>>>> imported to the best of my knowledge. 6004 was the last SVN commit >>>>> included. There have been a couple commits on the GIT repository >>>>> after the import. >>>>> >>>>> I believe we should start directing people to the new repository, and >>>>> if possible change the existing one to read-only. I don't think we >>>>> should delete it until more time has passed. >>>>> >>>>> We should decide on our suggested workflow for issues / pull requests >>>>> / feature branches. The castle project folks might be able to provide >>>>> some insight here, since they went though a similar situation. >>>>> >>>>> > We need to decide how to handle the existing SVN-based patches that >>>>> have >>>>> > been attached to still-open JIRA issues. Properly applying these to >>>>> TRUNK >>>>> > as the contents of the SVN and git repos diverge over time is >>>>> probably going >>>>> > to be a non-trivial process (unless someone has some pearls of wisdom >>>>> to >>>>> > share re: tricks for handling this simply...I've never actually tried >>>>> to >>>>> > apply an SVN patch to a non-SVN-controlled set of files...is this >>>>> even >>>>> > possible???) >>>>> >>>>> The SVN patches are almost just unified diffs. These can be applied >>>>> without much effort using generic patch tools. >>>>> >>>>> For example: >>>>> http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-git >>>>> >>>>> The patches in JIRA tend to be small or require significant >>>>> modification anyways, so I don't think this will be a major issue in >>>>> practice. >>>>> >>>>> Patrick Earl >>>>> >>>> >>>> >>> >> > > > -- > Fabio Maulo > >
