Tags not up to date

There is no new tag yet because there is no new release yet (same thing in our case). What configure.ac.in contains in the meantime is not really worth considering.

A discussion about this has already started in !1 (comment 41923), but I guess opening a new issue for this is not a bad idea.

@erxus what do you think is missing before we can do a first (development) release?
@andreldm what do you think would be the right version numbering? 4.15.x or 4.17.x? In the second case, I guess we'd have to release 4.18.0 before Xfce 4.18, but maybe that's ok?

Before first developement release I like to fix following things:

Fix distcheck errors (currently I am working with this)
Recheck calendar week view. I think that there is one regression, which was introduced by me somewhere in last 6 months.
Dynamic icon does not align lower line correctly in some languages (Estonian).
Figure out and fix reminder memory leaks.

Fix distcheck errors (currently I am working with this)

What are these errors? Are you referring to what @skunnyk said in !1 (comment 42336)? Because I just did a make distcheck to see and I found no problem.

This is not an error "per se", but we have logs like :

mkdir: cannot create directory ‘../../orage-4.16.0git-081bd3c9/libical/zoneinfo/.’: File exists

What about the bundled libical btw ?

Also, orage is still using dbus-glib which is deprecated since around 2017 iirc (can be fixed later)

About the version, I think the next stable should be 4.16.x, to be coherent

And we can add gitlab-ci tests !

And we can add gitlab-ci tests !

What is this? Anything to add in .gitlab-ci.yml?

Yes! xfce/xfce4-dev-tools#45 (closed) :)

I have following distcheck error:

XGETTEXT_ARGS="--keyword=Q_ --from-code=UTF-8" INTLTOOL_EXTRACT="/usr/local/bin/intltool-extract" XGETTEXT=": --keyword=Q_ --from-code=UTF-8" srcdir=../../../po /usr/local/bin/intltool-update --gettext-package orage --pot
Can't exec ":": No such file or directory at /usr/local/bin/intltool-update line 713.
Use of uninitialized value $version in pattern match (m//) at /usr/local/bin/intltool-update line 714.
 *** GNU xgettext is not found on this system!
 *** Without it, intltool-update can not extract strings.
rm -f missing notexist
srcdir=../../../po /usr/local/bin/intltool-update -m
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.

sub/globaltime/globaltime.desktop.in.h
sub/panel-plugin/xfce4-orageclock-plugin.desktop.in.h
sub/plugin/xfce-xfcalendar-settings.desktop.in.h
sub/xfcalendar.desktop.in.h
globaltime/globaltime.desktop.in.h
panel-plugin/xfce4-orageclock-plugin.desktop.in.h
plugin/xfce-xfcalendar-settings.desktop.in.h
xfcalendar.desktop.in.h

If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to xfce4-dev@xfce.org
if [ -r missing -o -r notexist ]; then \
  exit 1; \
fi
gmake[2]: *** [Makefile:181: check] Error 1
gmake[2]: Leaving directory 'xxx/orage-4.16.0git-081bd3c9/_build/sub/po'
gmake[1]: *** [Makefile:589: check-recursive] Error 1
gmake[1]: Leaving directory 'xxx/orage-4.16.0git-081bd3c9/_build/sub'
gmake: *** [Makefile:805: distcheck] Error 1

It is show up only when I set GCC compiler, normally with Clang it does not show up. Clang error was corrected with last MR !9 (merged).

If dbus-glib is not blocker then I like to fix it later after first release.

Bundled libical will be removed this summer or autumn. Mainly because libical 3.0 triggers lot of debug messages, and it seems that old and new one is not 100% compatible. So I like to wait least 6 months.

Yes! xfce/xfce4-dev-tools#45 (closed) :)

@skunnyk But I already added .gitlab-ci.yml, and that was enough to trigger the CI. Is anything missing?

@skunnyk But I already added .gitlab-ci.yml, and that was enough to trigger the CI. Is anything missing?

@Tamaranch I'm dumb :'(

*** GNU xgettext is not found on this system!

@erxus Yes gettext is mandatory, you have a PATH problem ?

PATH variable should be OK. It seems again that some tools/programs are wrongly detected on FreeBSD. I check this later today.

Actually Orage does not even compile with FreeBSD make.

Yes, you need to use gmake to compile xfce projects (this is not related to orage). You should try/look at other xfce projects, they are all working on *BSD, maybe something is missing somewhere in orage :)

Now I have run distcheck with several different setups, and it works on FreeBSD. gettext problem was related somehow with compilers: I started configure with GCC and accidentaly run distchek with Clang, and result was gettext error.

mentioned in commit 04b654dc

This is not an error "per se", but we have logs like :
mkdir: cannot create directory ‘../../orage-4.16.0git-081bd3c9/libical/zoneinfo/.’: File exists

Fixed in 04b654dc (I put this in another thread, because the other one will be overloaded otherwise :) )

mentioned in issue #4 (closed)

mentioned in issue #5 (closed)

changed milestone to %4.16.0

If dbus-glib is not blocker then I like to fix it later after first release.

Bundled libical will be removed this summer or autumn. Mainly because libical 3.0 triggers lot of debug messages, and it seems that old and new one is not 100% compatible. So I like to wait least 6 months.

I've opened dedicated issues for that, just to make it a bit clearer :) (see #4 (closed), #5 (closed))

About milestone 4.15.0. Before I started MR !1 (merged) then I marked version as 4.15.0, there was also one version 4.15.1 and first MR !1 (merged) was initially marked as 4.15.2. @andreldm left note about version numbering, and as I understand this remark that version should be 4.16.0. Anyway I don't have problem with 4.15.0 either.

Oh yes, I hadn't seen that comment. Well, it depends if you want to do a development release first or not.

I don't mind going directly to 4.16.0 if you want to. Anyway, I'm not sure if we really want to follow Xfce versioning afterwards, i.e. maintain a stable 4.16 branch, where we would only backport some fixes, and continue development on master in 4.17.x. Usually, applications follow their own cycle.

I guess it will also depend on how confident we are when this todo list ends :)

Hey, sorry for not answering before, even though I suggested make it 4.16, my point was about consistency since this app was already using a version scheme following Xfce core.

You can release 4.16 targeting Xfce 4.16 and 4.17 as a dev release if you want to make more significant changes separately (refactoring, new features, etc). IMHO I would decouple this app release cycle from Xfce's because it can be ready for 4.18 while the former isn't or Xfce can be ready but won't wait for Orage.

Milestone updated to 4.16 :)

Hey, I have completed most things which I planned to 4.16. Some issues still remain, but those are larger and are now planned to 4.17. Bascially I am ready to release 4.16.0, which I have initially planned as pure GTK3 port, and next versions for new features and bugfixes.

Only one thing I like to change: Orage has panel plugin,tz_convert and GlobalTime, and I think all those programs should be only compiled/installed when user ask so. tz_convert should be built only with bundled libical. I like to drop panel plugin support 4.17. Basically, panel plugin is very old fork from XFCE clock, and only difference from clock is that it open Orage when it clicked. I think that it is make more sense to modify latest XFCE clock to open Orage. Panel plugin was ported because I wanted to see what it is. GlobalTime just have multiple clocks in separate window, but multiple XFCE clocks can be configured similar way. @Tamaranch and @andreldm, any comments about changing autotools such way that these parts are built only when asked?

For tz_convert no problem, and I guess we can do without GlobalTime. But for the plugin it seems less clear to me.

I guess the user expects that clicking on the panel clock will bring up the Orage calendar if he uses Orage, so it's not a feature we can just drop. From that point on, I would think it's better for Orage to be self-contained in that respect. By the way, there is also the "datetime" plugin in addition to "clock", so ideally this one should also include a call to Orage.

In any case, I would rather leave it for version 4.16, and as long as "clock" and/or "datetime" don't integrate the call to Orage, if it has to happen.

Basically, panel plugin is very old fork from XFCE clock, and only difference from clock is that it open Orage when it clicked. I think that it is make more sense to modify latest XFCE clock to open Orage.

On second thought, this argument has some weight, and we can limit ourselves to the panel's internal clock plugin: after all, if the user is using the Orage plugin, he's not using the "datetime" plugin.

I guess we should make it work via D-Bus, the plugin sending to Orage the coordinates of the place where its calendar should appear?

Yes, exactly, this was one of my intentions.

Hi, I'm late to the party (as usual)... so tz_convert is optional (good) and you plan to disable by default GlobalTime and panel plugin as well? I don't know, I'm very reluctant to disable things just based on the assumption they are not really that useful anymore, especially when there is no replacement (yet). You can argue packagers can enable these features, but most of they time they just go with the sane defaults.

And I agree in making clock able to open orage, we can discuss the details later in another issue.

My suggestion is to leave both enabled by default and in release notes we mention they are deprecated, marked to be removed in the next major release. wdyt?

I have no objections to Andrea's proposal of keeping GlobalTime and panel plugin. And we should mark both as deprecated. Panel plugin can be removed when some other plugin is able open Orage, I hope that this will be next major release, but it is not yet my priority.

When thinking about future. Orage has Orage tray icon, which can also open Orage and have calls to mostly used Orage features. Tray icon uses deprecated GtkStatusIcon. I have not find any good replacement for GtkStatusIcon and I think that one possible alternative for XFCE is to use panel plugin (or write another plugin). Tray icon is something which I really want to remain avilable. @Tamaranch do you any hints about GtkStatusIcon replacement?

I agree with Andre's proposal as well. So if I'm not forgetting anything, we would be ready for 4.16.0? I haven't reviewed !15 (merged) in detail yet, but I guess we can merge it before without much risk. If not we can always do it after, there is nothing critical.

If you guys confirm that we are ready for 4.16.0, do you want to take care of it @andreldm? I can do it, but you'd have to give me permissions on releases.x.o :)

Regarding GtkStatusIcon, I don't know any more than you do at this point @erxus, I don't think I've ever touched it. I think it would be better to open a new issue for that, but if there is no obvious replacement, we can also just keep using it without worrying too much about deprecation in that case, I think.

@Tamaranch by no means I would dare to steal the honor of releasing Orage from you, permissions granted

Regarding GtkStatusIcon, my take is to not worry about it until porting to gtk4 and I believe some other Xfce devs think the same.

I think that 4.16.0 is ready to release, basic functionality seems to be OK. And fixing remaning issues is enless task anyway. About !15 (merged): it does not make big difference if it is merged to 4.16.0 or next release, it has some additional log lines.

mentioned in commit 0e30cbde

mentioned in merge request !18 (merged)

4.16.0 released! I tried to make the release notes a bit readable, and mentioned GlobalTime and plugin deprecation discussed above. I think everything is there. Well done and thank you all!

closed

mentioned in issue #11 (closed)

mentioned in issue #12 (closed)

mentioned in issue #21 (closed)

Tags not up to date

Designs

Child items ...

Activity