~jlkde

Germany

https://blog.jlk.one/

Product Owner @ univention.com

~jlkde/public-inbox

Last active 3 years ago
View more

Recent activity

A new hut release? Was: [PATCH v2] todo ticket create: new command 1 year, 9 months ago

From jlk to ~xenrox/hut-dev

Good day,

it's me again, the guy packaging hut for openSUSE and asking for a new release 
occasionally. :)
The recently merged feature to create tickets via todo is something that I 
waited for and I am quite happy that it is included now, therefore I would like 
to update my package.
What do you think about a new release as v0.2.0 is now 7 months old?

On a broader note: Is it ok that I contact you like this from time to time to 
ask for a release or would you prefer me to handle this differently?

Best regards
Jan-Luca

Re: New hut release? 2 years ago

From jlk to ~emersion/public-inbox

> Indeed, it's been a while since the last release, thanks for the ping.
> I've just released v0.2.0.

Thanks! Works great for me so far and the package update is queued too.

New hut release? 2 years ago

From jlk to ~emersion/public-inbox

Hey,

in the past I have contacted you twice regarding the release of hut and this 
time will be no different. :)
There are some openSUSE packages including hut maintained by me for whom I tend 
to pick up the latest release and perhaps hot fixes.
As the first/last release of hut happened in March some fixes and features got 
finished that I'd like to include, so would it be possible to release a new 
numbered version of hut in the future?
If the release approach does not follow numbered versions I would try to keep 
the package more or less up-to-date instead.

Best regards

Re: Release model of hut 2 years ago

From jlk to ~emersion/public-inbox

Hey,

>> I think it would be reasonable to publish a version sometime soon. I'm
>> still not 100% sure we won't change some flags or behavior, so maybe it
>> would be best to name it e.g. 0.1.0 to make the unstability clearer.
> I am pretty sure there will be at least some breaking changes (e.g. once
> some good usability for ACL updates is found, all services should
> probably use that).

That should be no problem as some breakage can be expected from devel packages 
and my guess is that users wanting to install hut already know about it's status.
For me keeping track of my maintained packages works better with some kind of 
release versioning and I don't think that a well-defined scope of releases is 
that important at this development state.