Hi Yonny, I think OSGI doesn’t have much footprint in the Industrial Automation area. I was just bringing up places where such a version number scheme would provide issues. I personally think OSGI is outdated and I like to stay clear of it. I think in many areas it’s too complicated. I guess that’s the reason why I haven’t seen OSGI being used in the automation industry.
However what I have seen in this sector is mostly single node MQTT brokers at the start and then moving from Mosquito etc. to commercial offerings as soon as the load requirements demand it. With BifroMQ we’d have the opportunity to start single noded and then to scale up without needing to replace the product. That’s what I really like about it. IoTDB for example … Is also intended to be used as a distribution and in dockerized form. However they never prevented any artifacts from being published to maven central. If someone wants to consume these, they can … but it’s not a formally supported way to deploy it. As I said: Once I get to the point that I want to add BifroMQ to my toolchain, I have no issues to locally build the artifacts and integrate them. Was just curious about the reasoning for not doing it (I think you need to do extra work to prevent the artifacts from being deployed). Chris Von: Yonny Hao <[email protected]> Datum: Freitag, 19. Dezember 2025 um 04:32 An: [email protected] <[email protected]> Betreff: Re: Versions and some Mentor advice. Hi Chris, Thanks for bringing up the OSGI angle and the concrete scenarios you mentioned, it is very helpful. BifroMQ originally grew out of a cloud-service system, and its current positioning is still very much aligned with building and operating large-scale distributed systems. Even so, although BifroMQ is designed as a distributed architecture, from a technical point of view it can also run as a single-node, fully functional runtime. Your comments about OSGI usage in embedded and industrial environments made me think further about possible future directions. It is interesting to consider whether BifroMQ could, in the future, be provided as an OSGI-compliant bundle, and be used as an embedded MQTT broker within the OSGI ecosystem. I believe this topic is broader than just making the version number more OSGI-friendly. This could be a good example of a community-driven proposal, where we first collect feedback and practical scenarios, and then evaluate whether and how such support should be implemented in future versions of BifroMQ. Thank you again for your time and for sharing your experience. Best regards, On Fri, Dec 19, 2025 at 2:05 AM Christofer Dutz <[email protected]> wrote: > Hi all, > > So … I just came back from a little time-out … so I had a gut feeling, > that a version of „4.0.0-inclubating“ causes issues and I tried to find > confirmation for that. I do know things change, and things that were bad > can turn out to become best practice. So, it’s always good to challenge > your own beliefs. > > So it is true that a version of 4.0.0-incubating has its downsides > compared to a pure numeric one. > > * > Version ranges don’t work correctly with them > * > OSGI has it’s issues with them > > But I guess in the case of BifroMQ, both of these drawbacks aren’t as > severe as for example in my own favorite project: Apache PLC4X. There we do > have people using OSGI and I am sure we have people using version ranges. > > So, I just wanted to loop this back to you. > > Also did I want to point out that just because you found projects doing > something the same way you were intending to, that doesn’t necessarily mean > that it’s considered best practice or even allowed. > > Unfortunately, we’ve seen that several times before, that one (most > polling) project does something. As they didn’t ask or discuss things > publicly, none of their mentors noticed. But then, other projects use this > pattern as confirmation that it’s allowed. > > Looking at TLPs I would consider pretty mature, but please don’t use other > podlings as reference. Not seldomly that even resulted in bringing the > spotlight on things that ended up with all podlings needing to drop that > pattern. > > The last time I remember something like that was when I questioned using > some AI based tool for „free community support“. > > > Chris > -- Yonny(Yu) Hao
