search

mcneel / rhino.inside-revit

This is the open-source repository for Rhino.Inside®.Revit
https://www.rhino3d.com/inside/revit/
MIT License
266 stars 69 forks source link

RiR namespace changes halfway through version 1.0 release? #592

Closed ThomasMahon closed 2 years ago

ThomasMahon commented 2 years ago

Versions

Rhino.Inside: 1.6 Rhino: 7 Revit: 2022

@kike-garbo have the namespaces changed somewhere between RiR version 1.0 and the latest release? I've had to reinstall RiR and noticed its broken our Revit app which uses it.

On the one hand I'm happy to see this update as the namespaces were excessive IMO but from an end-user perspective this is a nightmare. For example, our Revit app will break if our clients end-users download the latest version of RiR. It causes an unnecessary deployment challenge too - I'm now going to have to coordinate a company-wide upgrade of RiR with my clients users so they can continue to use our software.

Why are breaking changes not done in the conventional way following semantic versioning, i.e. version 2.0 for breaking changes?

ThomasMahon commented 2 years ago

I've discovered the namespaces haven't changed; instead the latest version is split across multiple assemblies. This still breaks my app.

When major changes like this occur why are they not coordinated with the dev-base? For example an email newsletter warning us of the breaking changes? More so if they're going to be rolled out willy nilly like this given that semantic versioning isn't in use.

sbaer commented 2 years ago

I'm confused about this issue. We purposely did not have a public SDK in 1.0 so we could get things "cleaned up".

ThomasMahon commented 2 years ago

@sbaer My understanding is that RiR is now an offical stable release and no longer in beta. Version 1.0 denotes a public API - at least that's always been my way of interpreting software versions (and also how we version our software).

My issue is, with the above in mind, why would breaking changes be rolled out like this?

The major problem I have now is I need version 1.2.7955.31573 or 1.3.7970.19099 installer as my client is not happy about the amount of effort its going to take to upgrade all their users to RiR v1.6 and coordinate this with our software and I cant downgrade which means I'm currently targeting an incompatible version of RiR for my clients local environment.

If breaking changes are going to continue (consolidating namespaces would be one I would like to suggest) and for all intents and purposes, RiR is still in beta despite its version number, can McNeal make all previous versions available for download so developers have more flexibility and don't end up in an unexpected quagmire I now find my self in!?

EDIT: I did contact technical support and request the installers earlier today but I'm yet to get a response and this is urgent as we need to deploy our software this week and cant while we are targeting the latest version of RiR.

ThomasMahon commented 2 years ago

@sbaer Another problem these types of breaking changes create is when our client on-boards new staff and their IT team deploy RiR so they can use our software - all they can download is the latest version which isn't compatible. This is also why its so important to allow older version of RiR to be downloaded.

kike-garbo commented 2 years ago

Hi @ThomasMahon,

The public API is documented here.

What other Types are you using?

ThomasMahon commented 2 years ago

Hi @kike-garbo thanks, but I'm not using much from RiR, its used as a bridge between Revit API and RhinoCommon so our app can utilize RhinoCommon. I'm using a few classes from the RhinoInside.Revit.External.UI.Extensions and RhinoInside.Revit namespaces but I'm not asking for documentation.

I need the installer for either 1.2.7955.31573 or 1.3.7970.19099. The problem we're having with v1.6 is the RhinoInside.Revit.External.UI.Extensions namespace is now in a different assembly so I cant target v1.6. If I do, then my clients users (60+) get an exception when they run the Revit app as its trying to find that namespace in the RhinoInside.Revit.dll. My client isn't willing to upgrade all their users to v1.6 and I cant send them updates (its daily as we're adding new features to their app) while I have v1.6 installed on my system. I had to install this version due to a Windows 11 error which forced a reset so all my software apps had to be reinstalled.

The simplest solution is to allow us to download previous versions of RiR so we can manage deployment. I'm not willing to clone the RiR repo either as this will most likely take an entire day to resolve all the dependencies and get it to compile.

Really, breaking changes shouldn't be happening in publicly releases of the software of the same version (i.e. v1 shouldn't have breaking changes). It causes too much disruption and makes planning our apps deployment strategies unpredictable and unreliable.

Can you send me the installers for 1.2.7955.31573 and 1.3.7970.19099?

kike-garbo commented 2 years ago

What I mean is that only Types listed on the documentation are for public use.

All other types are for internal use only and may change anytime. In order to avoid confusions, those types that are not documented because are not part of the public API were moved to other assemblies.

In order to allow your users update RiR without incurring in such a conflict you can move any code there is under RhinoInside.Revit.External.UI.Extensions to your assembly. There are only five utility methods on that namespace, and the content is pretty straightforward Revit API.

ThomasMahon commented 2 years ago

Thanks @kike-garbo and for clarifying how you are defining whats public or not. I've reduced all dependencies on RiR to just the RhinoInside.Revit.dll to mitigate any future changes.

Can you give me any insights into what kinds of breaking changes to expect going forwards? Will RiR get to a stage where and when to anticipate breaking changes (i.e. v2 release)? This is really crucial otherwise I cant plan any future updates of our app without a lot of uncertainty and testing.

ThomasMahon commented 2 years ago

@kike-garbo the msi's fail to download (i'm using alt+left click in chrome), can you email them to me?

kike-garbo commented 2 years ago

Everything is on the documentation should stay until v2.0. So you should expect no breaking changes until v2.0.

All additions to te public API will be done in RhinoInside.Revit.dll. Before we release any v2.0 it will be in beta-WIP phase some time for sure.

ThomasMahon commented 2 years ago

Thanks @kike-garbo this is useful to know.